pungi ignores a lot of RPMs when building CD image

Earl esammons at hush.com
Fri Feb 2 19:49:12 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Remy,

Excelent work!  I, for one, appreciate your effort.  Now that you
have re-inspired me, I have a basic comps.xml question that I
_think_ has already been answered here (pardon my dense-ness):  In
theory if you want to create a very stripped down subset of FC you
could:

1. Generate a list of package %name that yield no external
dependncies
2. Create "comps.xml" that only lists %name from (1) in a group
called "base"
3. Do the pungi pungi ;P

Is this correct?

Earl

On Fri, 02 Feb 2007 11:36:12 -0500 Remy Bohmer
<mythtv.bohmer at gmail.com> wrote:
>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
>> >
>> >
>>
>
>--
>Fedora-buildsys-list mailing list
>Fedora-buildsys-list at redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.5

wkYEARECAAYFAkXDlhAACgkQk7+e+4lPSm2O8QCeJENc6P4EPIp7FOovcYe9j6CbbZkA
oLuWDtzc5RdQdabfbniUajwiXZ+h
=40Tu
-----END PGP SIGNATURE-----





More information about the Fedora-buildsys-list mailing list