pungi ignores a lot of RPMs when building CD image

Remy Bohmer mythtv.bohmer at gmail.com
Mon Feb 5 16:53:50 UTC 2007


Hello All,

I thought I got it...  But this is not true... I have now the problem
reversed :-(((

By changing the first letter of the product name to a capital, the
result was that I have now a CD image of 331 packages, where I need
362. Before this change, I had 31 packages...

The problem is still pkgorder, at the same location as mentioned below.

For some reason pkgorder is really stubborn, and still mixes up the
productname by changing the first letter of several packages. It does
not matter where the packages come from, either from the orignal
FC6-DVD , or from the FC6-Updates repo, or from my custom repo. Even
if I build without my own repo, does not matter.
Notice that a bug in pkgorder does not even tell anybody if it can
find a package at all, it just continuous, resulting in an incomplete
CD-image...

So, does anyone know how the location of a package is determined in
pkgorder? (I mean the relative path inside a repo, with the product
name)

It does NOT read it from Pungi configuration file (Tried to change it
completely, no result)
Tried to change the product name on the commandline of pkgorder -> no
result either...

So, nowhere in my tree I can find the wrong productname, and neither
does any change of any product_name setting help.

I really hope, someone can help me out here... I am starting to get
quite desperate about these tools... :-((


Remy



2007/2/2, Remy Bohmer <mythtv.bohmer at gmail.com>:
> Hello All,
>
> I got it! but, it is very strange... ;-))
>
> I debugged the pkgorder script and found the following:
> * At the routine 'processTransaction()' the complete lists of
> dependencies is available, then it calls the routine
> printMatchingPkgs() to print the packages to standard, after it has
> checked that they are available.
> * The filemask that is passed to printMatchingPkgs() through
> 'fpattern', is build up as follows: <os-dir>/Product/package*. Where
> Product starts with a capital, but my product_name in the pungi
> configuration does NOT star with a capital. So, the product-dir in the
> os-dir does not start with a capital. So, no dependency files can be
> found, leaving a os-disc1 with just a few files in it...
>
> I searched through the entire tree several times, but nowhere I have
> listed the productname with a capital, so this capital must be
> introduced by the tooling itself ! (Fedora also starts with a
> capital... Redhat also, and probably other distros using anaconda
> also?)
>
> So, to be able to build a customised CD, you must use a product_name
> in Pungi that starts with a capital. I have changed this in my build
> environment and now it works!
>
> I believe the problem is introduced by collecting the dependencies in
> the routine addGroups() -> ds.ResolveDeps() in the pkgorder script.
>
> For me it is going to deep in the external tooling, which I do not
> fully understand yet how they work. Maybe someone else recognises this
> phenomenon and can pick it up from here?
> Or if someone can give me some tips on this, I can look further into it...
>
>
> Kind Regards,
>
> Remy Bohmer
>
>
>
> 2007/2/2, Remy Bohmer <mythtv.bohmer at gmail.com>:
> > Hello All,
> >
> > I renamed all my groups to 'core', 'base', 'base-x' and
> > 'development-tools', and it does not make any difference... So, I
> > believe it is not only related to the group naming in the comps
> > file... I am going to debug this some more today.
> >
> > If anyone has a good idea about this, please let me know.
> >
> >
> > Kind Regards,
> >
> > Remy
> >
> > 2007/2/1, Jesse Keating <jkeating at redhat.com>:
> > > On Thursday 01 February 2007 05:40, Remy Bohmer wrote:
> > > > Attached are the results of this command:
> > > > /usr/lib/anaconda-runtime/pkgorder
> > > > /home/me/cdbuildtree/results/myrelease/i386/os i386 myproduct
> > > >
> > > > I replaced 'myproduct' with 'Fedora'. No differences.
> > > > The produced list is exactly like the list of RPM's in my os-disc1-
> > > > directory. Thus, much too short...
> > > >
> > > > Does this give you some new ideas?
> > >
> > > It would appear that pkgorder doesn't know about the other groups you have in
> > > your comps file perhaps.  pkgorder is just a python script, I'd poke at it
> > > and see how it figures out the order, and see if perhaps you need to change
> > > your group names in comps.
> > >
> > > --
> > > Jesse Keating
> > > Release Engineer: Fedora
> > >
> > >
> >
>




More information about the buildsys mailing list