Le Mer 10 septembre 2008 18:41, Richard Hughes a écrit : > > 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. I think this is a gratuituous distinction, and a full-blown distro comps file and a 3-line catalog file are just both ends of the same installation spectrum (with lots of people that could use something in-between). >> 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? Comps has the format necessary for its features and is in fact it is much simpler than the pk catalog format for what it does. I was quite horrified to see how complex the pk catalog format was for what it does. >> 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. So you didn't consider the existing format, because XML is "bad", and you didn't think a lot about your format, since you'd decided beforehand it needn't scale. No surprise it feels as a quick and dirty hack. (actually it feels like a format the original XKB authors would have loved. And no that's not a compliment) These are not serious technical arguments. That's handwaving. If it's clean and simple enough to scale that helps three-line users too. If it's not that does not mean it's good for three-line users that just means the problems are spread out more, thus less obvious. And lastly *because* users don't enjoy writing any config file (be it XML or not) they *need* a validation tools that tell them where they made typos (instead of hunting manually for missing parenthesis and such stuff). >> 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. This means as soon as a project tries to support more and a handful of distributions it devolves in unmaintainable spaguetti mess. You've made it easy to write distro-specific exceptions instead of making it easy to write the common bits. Also, because you're mixing distributions but not considering scalability, that means a user that wants to check Fedora's cool configs site is going to need loading lots of different catalogs that all define stuff about distros he does not care about, instead of loading a single (or a limited number) of files that only target his distribution but at least are feature-complete. >> 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? In case you've not noticed it every installer be it anaconda or trivial windows aunt-tillie-oriented setup files expose component trees with some optional leaves, because optionnal nice to have but nor strictly necessary bits of an install set are a fact of life. This is one reason we do not do monster monolithic rpm packages because the #1 request of our users is always to have the possibility not to install everything in all cases. The trivial example is software with lots of possible plugins, themes, localizations, or other nice-to-have but not-strictly-necessary and broadband/disk-intensive resources. > I really do think it's two different file types and formats for two > different use cases. Honestly, it does not feel you've spent enough time thinking on the subject. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
