Feature Proposal: Use cases database

Richard Hughes hughsient at gmail.com
Wed Sep 10 16:41:03 UTC 2008


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.





More information about the fedora-devel-list mailing list