[Yum-devel] [PATCH RFC] Add new metadata type to comps

[James Antill]

 Sorry for not responding sooner.

On Wed, 2012-08-01 at 14:47 -0400, Bill Nottingham wrote:
> James Antill (james at fedoraproject.org) said: 
> > > >  From the backend POV, this looks fine to me (I assume the anaconda guys
> > > > are happy with the APIs they need?)
> > > 
> > > It's still being discussed.
> > 
> >  *nods*
> 
> Discussions there centered mainly around naming; the name of 'environment'
> was considered better than 'install class'. Updated patch attached.

 Environment seems weirder than install class, to me. But I'm not too
bothered.

> > > >  From the UI POV though I think we need to integrate it into the current
> > > > groups. So you could just do: yum install @blah ... to get an
> > > > "installclass" group. I assume there are no plans to have installclasses
> > > > with the same name as a normal group (so we can treat that as a WTF)?
> > > 
> > > Hadn't ruled that out one way or another - the other option would be to pick
> > > a new magic starting character other than '@'.
> > 
> >  I saw that suggestion in the anaconda thread, and I'm pretty sure it's
> > a terrible idea to have another magic character.
> 
> anaconda seems greatly in favor of (from a kickstart perspective) of
> treating it as a new item separate from groups, with a different delimiting
> character.

 The more I think of it the less sure I am, as it helps a bunch of the
UI stuff to have them be different code paths, but we still have the
problem that there just aren't that many characters to use (assuming no
utf-8 ... which, just no). Discarding the really bad ones gives:

 !#$%^~

...are probably the best six, and almost all of those seem bad (not even
100% on if any of them are valid in rpm names/versions). Almost all of
them suck to put on the command line too (and/or have problems in things
like mock install lines).
 I know anaconda people suggested '^', but that does weird things
(unescaped) in my zsh (but seems fine in zsh -f).
 How about something like:

 @group
 @^environment
 @:environment
 @@environment

...the later overloads ':' again, but maybe in a clear way. The '^'
doesn't look too bad to me with the @ (and doesn't need escaping here),
and '@' is kind of ok here, but is maybe confusing.

> > > >  Also are you sure you want to keep the feature that is display_order?
> > > 
> > > Can maybe drop it and just say for anaconda UI purposes it follows file
> > > ordering.
> > 
> >  Well I was assuming just using lexicographic order instead. Is there a
> > need to change the order (to always have minimal at the top or
> > something)? If so I guess just keep display_order, but given how we
> > never use it for groups and that users don't expect it I thought it
> > might be a good idea to not carry it forwards.
> 
> I would like to have ordering of some sort; if file ordering can't be
> preserved, then keeping display_order is best.

 Yeh, just keep display_order then.

> Comments, concerns, other?

 Can you do a patch relative to the first one ... as I'd already applied
that locally to do the other bits (I appologise for not pushing, I
really will do a push this week).