On Thu, 20 Apr 2006, Pascal Bleser wrote: [...]
I'm afraid to have to tell you, that there isn't much documentation on a technical level yet :( You'd have to dig into some YaST / libzypp / zmd packages, to find the answers to your questions. But as we move along, we will hopefully be able to deliver documentation on this in the future.
Keep in mind that as long as there isn't any documentation, it's more or less of no use outside of the SUSE team at Novell.
When you plan/implement such tasks inside the SUSE team, please consider spending a little bit of time on some decent documentation, a text file or a wiki page on opensuse.org is sufficient. (AJ: hint, hint ;))
Frankly, this stuff has been developed within a very short timeframe under extrem pressure, so nobody cared about documenting this yet ;(
That's also an aspect of "community", keep in mind your stuff isn't just intended to be used by a handful of people who sit on the same floor, in the same building (near the "harddisk mortuary" (Maxtorgraben) in Nürnberg
By the way, the Maxtorhof doesn't have anything todo with a well known harddisk manufacturer. It's called like this, as it is located close to the Maxtor (a city gate) and the Maxtorgraben (something like a "moat").
Is it backwards compatible with plain repomd ?
It is, as it's just an extension to what repomd offers out-of-the-box. So there are some more .xml files (one per patch) and the usual primary/filelist/other .xml files.
Ah, ok, it's additional XML files. Great :)
Check out http://download.suse.com/update/10.1/repodata/ for the details.
Allright.
What I can see there is * Plain rpm-md files: - filelists.xml.gz - other.xml.gz - primary.xml.gz - repomd.xml ==> extended with <data type="patches"> <location href="repodata/patches.xml"/> <checksum type="sha">...</checksum> <timestamp>1145376771</timestamp> <open-checksum type="sha">...</open-checksum> </data>
* Additional SUSE-specific files: - patches.xml <patches> <patch id="zypp-1261"> <checksum type="sha">...</checksum> <location href="repodata/patch-zypp-1261.xml"/> </patch> ... </patches> - a lot of individual patch-*.xml files (with a quite complex structure)
Well, everything seems pretty straightforward, except the patch-*.xml files.
Right ;)
I assume you've got some tooling to generate those, as well as a modified createrepo, right ?
We don't have a modified createrepo for this, but we have our own set of tools to generate those files. The current generation of those tools is tied very closely to our internal build system & infrastructure, so we won't be able to release it as-is. But I can assure you that we will have tools to create that metadata in the future.
How can we use those ? - modified createrepo ? (that mentions <data type="patches">...</data> in the generated repomd.xml, and generates the patches.xml file) - tool to generate the patch-*.xml files ?
Actually, it's createrepo + tool to generate patch-*.xml files. The first part is easy, the other a bit more complicated.
Which makes me think that... err... once y2pmsh will really be dead (i.e. non functional), y2pmbuild must be ported to something else. To smart ? Or is there some form of CLI driven package installation tool with libzypp ?
y2pmbuild should be fully functional with the BuildRequires expansion stuff that went into build.rpm -- there is no real need to use y2pmsh, IIUC.
Mmmmm.. not quite, as y2pmbuild uses y2pmsh to install missing BuildRequires into the build chroots.
Right, but that could be done by simple rpm calls + the BuildRequires expansion that comes with build.rpm! y2pmsh is only used to compute the dependencies, IIUC. Regards Christoph