[gentoo-user] Re: This nite's switch to "full multilib"

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:


> > I think we need to get away from solutions that clutter up
> > configuration in the first place.  I'm not under any illusions that
> > this will ever be perfect, but I do think we can do better.

Amen.


> Agreed, but this is about managing the options we have now. Like it or
> not, we need to put extra entries in package.use and eix-test-obsolete is
> the best current way of removing them when they're no longer needed, as
> portage's autounmask facility only adds to the file, it never cleans up
> after itself.

And Amen, brother. As stated before, it reminds one of parenting where
teenagers must take responsibility to clean up after themselves. GLEP 64
will go a long way to providing the framework for tool/code creation
to clean up many, many errant files on gentoo. In fact if one were
to desire building a system that is fully verified, you'd need something
like GLEP-64 as the beginning or organization and tracking of what
it's installed. Granted EAPI-5 is moving in the right direction, and it
looks like we are moving to make that a requirement for all packages on gentoo.

 On my journey to learn more deeply about gentoo, I have looked closely
at dozens and dozens of packages, maybe over 100. It is a freaking mess.
Little consistency or structure or requirements from long ago, still
have their remnants of effects.

I find eix-test-obsolete (ETO) only produces valid things to address, at the
lower end of the 20% mark. There is no way to 'tame the best' on it's sputum
so I do not use it.  The best ETO can do is suggest a list of things to look
at (manually) for possible need of attention. If folks  are really concerned
about efficiency; it is quite easy to "prune" portage manually.  I use
scripts based on size or date, when I feel the need. Remove something
important?: just --sync and download again; no worries. After all one can
--sync to get something back if it is lost and of value.  As I find
attachment to codes that I want some permanency, I just replicate them into
/usr/local/portage. I  often like to keep old codes around (a very valid
reason for 2T drives) to look at various codes and how they evolved. The
various eclasses one package uses versus the eclasses chosen by another dev
to package up a code. ETO thinks old codes and old kernels are cruft. I
think the myriad of files spewed when some ebuilds are installed are cruft
and they are often not accounted for when packages are removed. 

So let's all get behind GLEP-64 so folks can build some real tools
for cleaning up and maintaining gentoo based systems.  If you
really want to "get up" on this issue, read up on "Directed Graphs",
particularly DAGs, and you'll begin to understand  what is possible
if GLEP-64 is *pushed* via the user base as a demand for those motivated
devs to move us to a GLEP-64 compliant gentoo. 

Currently, unless you manually groom your gentoo system(s), you end up with
a pig_sty as remnants of  codes, installs, configs etc etc just pile up and
it takes a "one off" inspection to filter many files as to "should I stay or
should I go now" (old punk lyrics....).


It is way past time for gentoo to offer robust tools for monitoring
and cleaning out cruft. What is cruft, needs to definable by the system
owner. So the codes and tools will need to be flexible to fit the needs and
desires of the user base, and therein we have much work to do, imho.


hth,
James