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" <waltd...@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 <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
