[Yum] pkg groups

Connie Sieh csieh at fnal.gov
Fri Jun 14 16:20:40 UTC 2002


After talking to Troy some more on this issue.  In the case of the install
the comps file would have indicated "X Window System" because of the "1".
So when the person selected KDE it would figure out the conditional ok.
There are only 3 ways to enable groups during a install.  The group has a
"1" which indicated it is selected by default,  the user selected it,
some other group included it.  So if the defaults are still the same that
part will work ok and the problem is only with the things that the person
selected which includes both the 2 and 3rd options above.  You could
either ask the user if they "Have" the conditional, have a default for
always selecting them as if they have them or ignore it completely.  I
suggest both the ask choice and the method of indicating a "default".

-Connie Sieh
Fermi National Accelerator Laboratory

On Fri, 14 Jun 2002, Connie Sieh wrote:

> Seth,
>
> On Fri, 14 Jun 2002, seth vidal wrote:
>
> > Hi all,
> >  Running into a conceptual snag with pkg groups I wanted to probe the
> > list about.
> >
> > so I first thought that using the red hat comps format would be
> > common/familiar and expandable enough for most people.
> >
> > Then I looked in more detail at the problem of conditional pkgs.
> >
> > ie:
> >
> > 0 group name here {
> >   pkg1
> >   pkg2
> >   pkg3
> >   pkg4
> >   ? conditionalgroup {
> >     pkga
> >     pkgb
> >     pkgc
> >   }
> >   pkg5
> >   pkg6
> >   pkg7
> > }
> >
> >
> > in this example - if the group conditionalgroup is tagged to be
> > installed then also install pkga, pkgb and pkgc
> >
> > That works great in anaconda b/c it knows which groups are tagged as
> > installed.
> >
> > Doesn't work so well when there is no group-state being maintained.
> >
>
> Why not just "assume" that this is what they want.  Just exactly as the
> group indicates.  Do not remember or try to figure out what they have
> already.
>
> I do not know why you want groups but my need is the case where someone
> installed say 7.3 and picked "GNOME".  Then later they decide they want to
> add "KDE".  The "KDE" group contains lots of stuff.  It would be really
> nice if yup could figure out all of that "KDE" group and install it along
> with the conditional dependencies.  Some things may already be installed.
> If so you have the choice of skipping those or installing them over.  I
> guess the functionality I am looking for is similar to a update install
> where you would in my example above select "KDE".  RedHat would then
> install "Base"(You always get Base even if it if there and ok) and you
> would get "KDE" too.
>
> So based on this I think you need to keep comps.
>
> --Connie Sieh
> Fermi National Accelerator Laboratory
>
> Yep I work with Troy Dawson.  We are searching for a replacement for
> autorpm.
>
> > So the options are: > 1. maintain state on group selections
> >  - this breaks badly when first starting up - how will it know which
> > groups you selected in anaconda?
> >  - this breaks b/c groups have no hold over what gets erased and
> > therefore you could intentionally remove a pkg you don't want but have
> > it get added back in b/c of a group dependency.
> >
> > 2. don't maintain state and use the groups solely as pkg lists, ignore
> > conditionals entirely.
> >  - thats just irritating to the user who knows that yum reads the comps
> > file but only _mostly.
> >
> > 3. don't use the comps format at all, do something else, far simpler as
> > install/update groups.
> >  like:
> >   group name
> >       pkgname
> >       pkgname
> >       pkgname
> >
> >  group name
> >      pkgname
> >      pkgname
> >
> > and just have them be sucked in by python in some way.
> >
> >
> >
> > part 2 of the problem:
> > how to deal with groups on multiple repositories.
> > if I'm trying to install group "foo" and both server1 and server2 have a
> > group foo which do I choose.
> >
> > there would be no way to determine who had the newest foo so we could
> > just use "last in wins" as the rule. That could cause some issues - but
> > you should know what groups etc your repositories are providing, right?
> > :)
> >
> > I'm open to suggestions at this point.
> >
> > My first thought is to just do simple groups and last-in - its quick,
> > its functional and it will probably satisfy 80% of what I need and most
> > people need but I'd love to hear ideas.
> > thanks
> >
> > -sv
> >
> >
> > --
> > GPG Public Key: http://www.phy.duke.edu/~skvidal/skvidal.gpg
> >
>
> _______________________________________________
> Yum mailing list
> Yum at lists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum
>




More information about the Yum mailing list