On Wed, 2008-09-10 at 18:02 +0200, Nicolas Mailhot wrote: > Please work with the anaconda team so whatever resource list format you > end up is shared and we don't have pk catalogs vs comps files. I think they are two different formats for two different use cases. > Really our comps file is nothing but the initial catalog restricted to the > initial repository and it's quite disturbing they have ovelapping > functionnality with different featuresets, syntax and limitations. Comps has optional packages, groups, and quite a complex format. Could you write a comps file from memory without copying an existing one and modifying it? > On the positive side: PK catalogs allow specifying resources via > something else than package names Yes, as distros are usually spectacularly bad at deciding on package names (looking at you Debian). > On the negative side > 1. They use .ini syntax. Does not scale well, the fact comps file > are .xml had helped set up things such as syntax verification easily Right, I guess that's another key distinction. Users write catalog files. Users don't usually enjoy writing XML, unless they are sadist programmer types. I also don't intend on having super complex catalog files, so that don't need to scale. Typically they will be a three lines long at most. > 2. They are keyed on distro-id and architecture. Really this is an > abysmal idea (as showed by the example asumption Rawhide is fedora > 9.90). If you really want a multi-distro multi-release file at least > separate cleanly the different bits in separate sections. No, if you look at the file then you'll see as much stuff is common as possible. This means distros with sane naming policies (say, for instance Foresight) don't have to have "support added" by adding an extra section, they just work. distro_id's make a lot of sense when doing this sort of stuff. > 3. They have no structure you can't define groups with > optionnal/default/etc bits. Anything not limited to a handful of > packages will need this Why optional? If you need packages x, y and z to get started hacking on Xorg, why would you possibly need package a as well? If you possibly need it, include it in the main package list as catalogs are not designed for l33t hacker types who want to keep the number of programs installed to a minimum. I really do think it's two different file types and formats for two different use cases. Richard. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
