On Wed, 26 May 2004 17:32:18 +0200, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > And this is where you didn't listen to me. > All the world is not a yum repo. yum is an example of mature comps.xml usage anaconda and system-config-packages are other examples..i won't comment on the maturity of them :->. I'm saying teach ALL the tools to use comps.xml more effectively becuase right now the in distros use the groups tag for pretty much...nothing. > Right now yum is an *optional* rpm overlay. > If you make yum mandatory for something as trivial as rpm classification > you kill a lot of rpm's interest. I would say ALL grouping information should be optional.... > > How do you handle single-rpm publication on sf on your setup ? How do > you handle rpm -Uvh http://foo.org/bar.rpm ? How do you handle using a > CD of unindexed rpms as a yum source ? I know before hand what those packages actually do...or i read the summary information and the the Description that gives me CONTEXT. I have certaintly NEVER gone...hmm i wonder if crackattack.i386.rpm is a a game or a gnome game or a kde game by looking at the group tag. I read the package summary and description or for fun...i dive into freshmeat's searchable trove for it. > Are you seriously suggesting someone needs all the repository plumbing > just to declare a package is a game, a gnome applet or whatever ? No im saying declaring its a game via a tag is POINTLESS. Becuase that tag is limited and doesn't really give much in the way of group handling abilities at the tool level. If the summary and the description don't make it clear its a game...something is already very wrong...why do i NEED the group tag. > > The group tag is broken mostly because it is > 1. mono-valuated hold your breath on getting that to change inside rpm.... > 2. not standardised there is a actually a list of conanoncal groups..../usr/share/doc/rpm-4.2.1/GROUPS And I argue that ANY attempt to standardize this group definitions is ultimately short-sighted. I think that groupings NEED to be flexible to account for as much new functionality to be future-proof. comps.xml is future proof because the NAMES of the groups themselves are not important in comps.xml..its the relationship between groups that is important in comps.xml. You standardize on a set of names and yer pretty much garunteed that at somepoint that set of standard names isnt going to be intuitive anymore and your constantly trying to fight the need to keep old names compatible with the new more intuitive names if the group tag is inside the packages themselves. Stop the madness, pull the group crap out of the packages and let people who build collections of packages work out how the packages should be grouped seperate from the build process. > 3. interpreted as-is instead of getting through even the dumbest > filter/formatter xml is more flexible....packages can be listed in multiple groups..yer not going to easily get that in the group tag in a package...especially if the multiple groupings you want to place a package in are an evolving set. > Frankly nothing I've read so far justifies moving this info out of the > spec files and making yum an hard requirement. Changing the > format/allowed values yes. Changing the way it is parsed/interpreted > yes. Moving it out ? No. Its already moved out...the in distro tools that are parsing for useful group definitions are using comps.xml. Nothing in distro uses the group tag for anything useful in a tool specific. We can keep pretending like this has been an historically useful tag...but it hasn't. > > You have to give a lot more compelling arguments than "it works better > than foo known-broken-for-ages setup" to sell something that goes > against package=standalone software unit rule. see thats sort of the point... grouping information is NOT useful in a standalone situation. Group information is ONLY useful when we are talking about multiple packages. Sort of the definition of a group of packages. If people are building standlone packages..i see no reason for them to impress on the people 'grouping' packages their pre-concieved ideas. The package description and summary should be more than enough to 'hint' to people who are 'grouping' stand alone packages into groups that makes intuitive sense to them. -jef
