Add a parser for updateinfo.xml

[thutterer]

This PR adds a new RepomdParser::UpdateinfoXmlParser and with it, a RepomdParser::Update class, representing individual updates. Each update comes with a list of packages. Details in the README.md changes.

@ikapelyukhin Please review and advise on the following questions:

• I haven't finished writing the specs. I wanted to ask you first if you could provide the real updateinfo.xml for your "apples and oranges" repo. I guess you have this somewhere on OBS, or did you handcraft it?

• Any caveats I might have missed?

Thanks!

[ikapelyukhin]

Hey, @thutterer.

This PR adds a new RepomdParser::UpdateinfoXmlParser and with it, a RepomdParser::Update class, representing individual updates. Each update comes with a list of packages. Details in the README.md changes.

* I haven't finished writing the specs. I wanted to ask you first if you could provide the real updateinfo.xml for your "apples and oranges" repo. I guess you have this somewhere on OBS, or did you handcraft it?

You can actually see where the repo came from in its metadata:

repomd-parser/spec/fixtures/files/dummy_repo/repodata/abf421e45af5cd686f050bab3d2a98e0a60d1b5ca3b07c86cb948fc1abfa675e-primary.xml

Line 17 in 12b1f01

<rpm:vendor>obs://build.suse.de/Devel:SCC:rmt-dummy</rpm:vendor>

So a long time ago, when dinosaurs roamed the earth and RMT was still called Potato, there was Devel:SCC:rmt-dummy in IBS. But in our infinite wisdom we have nuked it, so it's gone now (an by "we" I mean "it probably was me who did it, but I don't remember for sure" 😬)

Since then I have created home:ikapelyukhin:dummy_repo in OBS, which has the same packages but the metadata is slightly different (build times, etc.).

It doesn't have updateinfo.xml, however. I'm not sure how to force OBS to generate it, might be some dark prjconf magic. It seems to be generating only for release real release projects. Feel free to ask OBS or build/maintenance folks about how to enable it for a random OBS home project.

Another option would be to just get an updateinfo.xml from some repo (e.g. Leap 15.2) and trim it, leaving only 5-10 patches. I don't think we actually care in specs if those RPMs are present in primary.xml or not, as long as updateinfo.xml parses it should be all good. So that'd be another fixture dir with just updateinfo.xml in it.

* Any caveats I might have missed?

No, not really. I've taken a look at the current code and it LGTM. Just needs specs and we are good to go.

[thutterer]

Hi @ikapelyukhin, happy new year!

I haven't finished this one before the holidays as I ran into one small problem with the code in its current state.

An update section in an updateinfo.xml lists its packages, but each package only gives the filename, not the full location within the repo.

In my current code, I treat that filename as the location, which is a bug, I think, since the location should also have the relative path.

In most SUSE repos I've checked the folder name is just the arch, but is this an assumption I can make to fix my code? Or would this be just another bug waiting to manifest?

[ikapelyukhin]

Hi @ikapelyukhin, happy new year!

Thanks, to you too! 🌲

An update section in an updateinfo.xml lists its packages, but each package only gives the filename, not the full location within the repo.

In my current code, I treat that filename as the location, which is a bug, I think, since the location should also have the relative path.

In most SUSE repos I've checked the folder name is just the arch, but is this an assumption I can make to fix my code? Or would this be just another bug waiting to manifest?

Hmm, you have to provide examples.

    <pkglist>
      <collection>
        <package
                name="ruby2.5-rubygem-bundler"
                epoch="0"
                version="1.16.1"
                release="lp152.4.3.1"
                arch="x86_64"
                src="x86_64/ruby2.5-rubygem-bundler-1.16.1-lp152.4.3.1.x86_64.rpm"
         >
          <filename>ruby2.5-rubygem-bundler-1.16.1-lp152.4.3.1.x86_64.rpm</filename>
        </package>
      </collection>
    </pkglist>

Something like this? Isn't the full path in //package[@src], rather than //package/filename/text()?