Mailinglist Archive: opensuse (3337 mails)

< Previous Next >
Re: [opensuse] bug fix support by community
  • From: Christoph Thiel <cthiel@xxxxxxx>
  • Date: Thu, 20 Apr 2006 17:14:54 +0200 (CEST)
  • Message-id: <Pine.LNX.4.64.0604201642210.16456@xxxxxxxxxxxx>
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
< Previous Next >
Follow Ups