[Yum-devel] groupreq in yum-2.6?
rtlm10 at gmail.com
Sat May 13 18:44:42 UTC 2006
I should point out that mock builds are broken currently on FC5 because it
uses yum 2.6. groupreq is used by the fedora extras build environment to
include various levels of builds. When mock initiates the chroot it does a
"yum groupinstall build" which should pull in build-base and build-minimal,
and doesn't on FC5 machines.
This conversation was very timely. Now I know why the macros weren't
getting set properly.
On 5/13/06, Jeremy Katz <katzj at redhat.com> wrote:
> On Fri, 2006-05-12 at 16:29 -0400, seth vidal wrote:
> > > Instead of "only used by yum (cli application)" I'd rather see it as
> > > "implemented in yum libs, used where it makes sense" kind of thing: I
> > > think it'd be a pretty cool native kickstart feature but doesn't
> > > make sense for pirut. And certainly I'd want to add support for it in
> > > repoquery so you can easily see what would actually get installed with
> > > your profile definitions etc.
> I think this fits in well with my thoughts of more metadata files for
> things like this and having official and unofficial extensions. Also,
> the more I think about it, the more I like that as the unofficial things
> gives a good way to play with new features (like this) without tying
> down implementation details right away.
> > It's a weird location for it - but I'd think of naming it something
> > like:
> > <collection>
> Collection has a different meaning to me due to silliness with the Red
> Hat internal buildsys, but I can see it making some degree of sense.
> But does something like, eg, groupset make more sense? eg, make it
> explicit *exactly* what we're talking about.
> > then the operations on them would be:
> *nod* looks about right. We could even implement it as a plugin ;)
> > my questions are:
> > 1. does that make sense here
> > 2. is the collection name sensible
> > 3. will that screw up the thoughts for anaconda and friends?
> I think that making it higher level and explicitly separating it out
> starts to make sense as you can have different apps caring about
> different "representations" of things, as it were. And that's fine.
> Yum-devel mailing list
> Yum-devel at linux.duke.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Yum-devel