pungi ignores a lot of RPMs when building CD image

Remy Bohmer mythtv.bohmer at gmail.com
Mon Feb 5 20:20:51 UTC 2007


Hello Jesse,

What you mention is exactly what I want, except my product is not
named Fedora, but something else...
I will summarise the facts here below, hope this clears something up.

> Are you putting packages into different directories under os/ ?
No, the /os/ is an intermediate buildresult of what pungi (with
anaconda) is doing. I am not modifying it in any way. My goal is to
use as many standard tooling as possible, without the need for me to
modify the tools. (Except if there is a need for a bugfix)

So, only 1 directory with packages is there in /os/myproduct, not 2.

But after building the /os directory pungi calls at some point
pkgorder and this one introduces a problem while building the
os-disc1/myproduct directory.
I can reproduce it easily while just running pkgorder on the /os tree
that is generated by pungi, as you earlier suggested.

During build and debugging pkgorder, I have seen that
processTransaction() searches for the relative path of a package. This
path is mostly called os/Myproduct (Uppercase-M) instead of
os/myproduct. (Lowercase-M) os/Myproduct (Uppercase-M) does not exist,
so the package cannot be found. (the lacking 631 packages) Some
packages are searched in os/myproduct (lowercase-M), and these are
found correctly. (the 31 I had)
Due to a bug in pkgorder this 'file-not-found' issue is not visible to
the outside world. I have a patch for this, so that this it is at
least visible that this happens.

As a test, I have renamed the product_name to Myproduct (Uppercase-M).
If I do that I end up with 631 packages in /os-disc1, lacking the 31 I
had while using the lowercase M.

The packages that are searched for, in the wrong directory, can come
from any repo, i.e. fc6-dvd, fc6-updates, or my own custom repo, but
always the same packages go wrong.

> Are you getting multiple product dirs somehow?
I am thus NOT getting multiple product dirs in /os-disc1. It is not a
destination (/os-disc1) problem but a package gathering problem from
/os.

Do you have any idea how the relative-paths are resolved from the /os
repository?
I am certain that the cause is there somewhere, but I already spent 2
days debugging pkgorder with pdb, and it does not bring me any closer
the root cause :-((
I do not understand the relation to yum/package-dictionaries etc.
Notice that I have verified that dependency resolving works fine...

I really hope you can help me on this...


Kind Regards,

Remy



2007/2/5, Jesse Keating <jkeating at redhat.com>:
> On Monday 05 February 2007 11:53, Remy Bohmer wrote:
> > 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... :-((
>
> Er, Are you putting packages into different directories under os/ ?  I'm
> pretty sure that the way pungi is designed, all your packages would (by
> default) go under os/Fedora/   ALL packages, regardless of what repository
> they come from.  Are you getting multiple product dirs somehow?  I'm
> seriously having a hard time figuring out how you're getting to this stage.
>
> --
> Jesse Keating
> Release Engineer: Fedora
>
>




More information about the buildsys mailing list