[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rpm groups and fedora: a modest proposal

On Wed, 26 May 2004 17:32:18 +0200, Nicolas Mailhot
<nicolas mailhot laposte net> 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
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

> 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]