Re: [gentoo-dev] Sets vs Meta ebuilds

[Walter Dnes]

On Sun, Jul 09, 2017 at 09:49:08AM -0400, William L. Thomson Jr. wrote
> On Sun, 9 Jul 2017 05:24:19 -0400
> "Walter Dnes" <waltdnes@××××××××.org> wrote:
>
> >   Yes, for gcc.
>
> Which if someone ignores warnings, and breaks their system, it is on
> them. At that point your best to remove said package from the set, and
> then proceed with removing the set.

  "Fat-Finger" does happen once in while.  Removing the risk of it
happening in the first place is a lot more robust/bulletproof.

> >   If / when I unmerge the meta-set, I want to only unmerge stuff that
> > is not part of (packages I normally require).  I do not want all
> > members of the set unmerged unconditionally, regardless of being
> > dependancies for packages I still have.
>
> That is  a matter of knowing what is in the set and on your system. In
> that case the idea for a set would be to add packages that are NOT part
> of your normal system. Adding packages part of your system would defeat
> the benefit.
>
> >   This is where a meta-package is superior to a set.  I simply unmerge
> > the meta-package, and "emerge --ask --depclean".  If a meta-set item
> > is a dependancy of a package that I'll be keeping, it won't get
> > removed.  I do not want to risk removing a package that is needed
> > elsewhere.  And 2 or 3 years later, I may have installed packages
> > that have members of the meta-set as a dependancy.  A meta-package
> > removes the risk of shooting myself in the foot.
>
> Yes in the case you just add stuff into a set, not paying attention if
> it is a dep of another package, present or future. Then a meta ebuild
> does allow someone to be "lazier" ( not insulting you ) and know less
> about their system and packages. Just toss package names into a ebuild,
> and not worry if its a dep or not, past, present, or future.

  Everybody who doesn't run LFS (Linux From Scratch) is "lazy" in that
regard.  Figuring out dependancies is the job of a package manager, not
the end-user.  I may be getting old, and my head may be slowly becoming
like that of Captain Picard in STTNG (Star Trek The Next Generation).
I do appreciate being able to decide I want something installed and
telling Portage to "Make it so", and letting it take care of details.

a) I don't want to have to spend time figuring out if an item is or is
not a deep dependancy of a package I currently have.

b) I may install other packages later on which may have items already in
the set as a dependancy.

c) Even if *I* don't change "world", GNOME's ever-growing hard-coded
dependancy list will change.  hicolor-icons is just one example.  I use
ICEWM as my WM, with no DE (see my sig).  But gnumeric is/was a good
spreadsheet that I need.  Over the years, I've seen stuff added to
gnumeric's dependancies like "goffice", "ghostscript", "harfbuzz",
"dbus", etc, etc.  Most of that comes via GTK3.  I wouldn't be surprised
if GTK4 adds pulseaudio and/or systemd as hard-coded dependancies.  I'd
love to see somebody port gnumeric and Pale Moon to use FTLK
( http://www.fltk.org/index.php ) instead of GTK, to get away from that
bloat.  Too bad I'm not a programmer.

> It is a way to go, but others may want more fine grained control and
> have more awareness of package dependencies, and only add non
> dependent non-system packages to a set.

  Assuming it's not a lot of additional work, what exactly do sets allow
that meta packages don't?

-- 
Walter Dnes <waltdnes@××××××××.org>
I don't run "desktop environments"; I run useful applications