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
>
