Pungi now works from a flat file package manifest to decide what to depsolve and pull into a spin. A master comps file will be used for all spins for grouping purposes, so that grouping is constant, and only changed in one place. (I'm working from a merged comps-fc7 (slightly updated from FC6), and comps-fe7).
I've updated the wiki page with the latest data on the manifest + what it brings in via depsolving:
http://fedoraproject.org/wiki/Releases/FeatureFedoraDesktop
On Wed, 2007-01-24 at 12:42 -0500, Jesse Keating wrote:
Pungi now works from a flat file package manifest to decide what to depsolve and pull into a spin. A master comps file will be used for all spins for grouping purposes, so that grouping is constant, and only changed in one place. (I'm working from a merged comps-fc7 (slightly updated from FC6), and comps-fe7).
I've updated the wiki page with the latest data on the manifest + what it brings in via depsolving:
Does the manifest, e.g.
http://fedoraproject.org/wiki/Releases/FeatureFedoraDesktop/PackageList
support wildcards? If not, it probably should as it's ugly to include all of aspell-*, m17n-db-*, openoffice.org-langpack-* manually. I'm sure that when one package adds a new language, someone adds a new input method etc. then we're going to forget it and due to the package not being heavily used it will take some time to get noticed.
Notably yum supports wildcards this and it's used for the live cd stuff to pull in all the relevant sub packages.
Alternatively, we could have meta packages
aspell-all
that pulls in all aspell-* packages. Notably, if we go down this route we can later have (making up regions on the fly)
aspell-RegionAmericas aspell-RegionWesternEurope aspell-RegionEasternEurope aspell-RegionAfrica aspell-RegionAPAC
which would make it very easy to build live CD's / spins targeted at certain regions.
What do you think? Probably our packaging standard committee should look at something like this (including possibly defining regions).
David
On Wednesday 24 January 2007 16:33, David Zeuthen wrote:
support wildcards? If not, it probably should as it's ugly to include all of aspell-*, m17n-db-*, openoffice.org-langpack-* manually. I'm sure that when one package adds a new language, someone adds a new input method etc. then we're going to forget it and due to the package not being heavily used it will take some time to get noticed.
Notably yum supports wildcards this and it's used for the live cd stuff to pull in all the relevant sub packages.
Not a horrible suggestion. I think theoretically it could... Post test1 of course.
desktop@lists.fedoraproject.org