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
