-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rafael Fernández López wrote: > Hi, > > This is not flame war. I love Gentoo, and it is the distribution > that > fits me perfectly, but I've been wondering this last year what things > can be improved in this wonderful distro. > > The first thing that I'd change is "etc-update" or > "dispatch-conf". I'd > suggest to create some kind of tool like "dpkg-reconfigure" in Debian. > More intuitive than reading /etc files and writing them by hand that is > more probably to be mistaken when writing.
I do agree that these tools fall slightly short of the goal - which IMHO it to effectively "manage" config files when updating packages, and to "dumb down" the management process. I've noticed that a majority of the *.conf updates (especially recently) tend to be changing the date(s) in the Gentoo copyright notice (from 2005 -> 2006) and/or cvs document version header updates (e.g. v1.5 to v1.6). I typically use dispatch-conf, so maybe this is what etc-update calls "trivial updates". Without going into too many specifics (since the thread wasn't started in a specific manner), one of my pet peeves about dispatch-conf is that the new, unmodified *.conf files take precedence. I know there's the "merge" option, and admittedly, I haven't quite figured out how to use that effectively. But if a new *.conf file is presented, shouldn't/couldn't it diff the new with the old and automatically incorporate the differences into the new *.conf file? More to the point, as I'm not familiar with "dpkg-reconfigure", or debian for that matter, why not point out specific short-comings of the existing tools? Or propose a better approach to solving the *.conf file management issue (philosophically or technically - i.e. write one)? > > Second thing that I'd improve is a security one. I know that > "emerge" > is a very cared package, but it is a script. Suppose that someone > commits portage with a emerge failure in its code (he forgot a comma > !!)... if someone updates portage won't be able to update it again > because it will fail ever and ever again... So I suggest to have a > backuped emerge script that we are sure that worked (like the last > emerge tool that was used), and if the new emerge tool is mistaken (so > that user doesn't need to know python) only has to run "regenemerge" for > example, and will have the latest emerge working tool. > > I don't know if this is technically a "security issue", moreso an availability issue (which, yes, technically falls under security in terms of confidentiality-integrity-availability, but in my mind falls slightly outside of the umbrella). While you present a valid concern, I believe this is addressed by the whole masking/testing process that is currently architected into portage. If a portage developer managed to leave out a comma when doing a cvs commit, it's *very* likely going to be found before portage is moved to the stable tree. Worst case scenario, if something like this *were* to fall through the cracks, grab your trusty install-CD and revert to a known-good portage snapshot. Between the lists/forums/announcements/wiki/etc., I'm sure that something like this would surface /immediately/. Just my 2¢... > > -- > gentux > echo "hfouvyyAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge' > > gentux's gpg fingerprint ==> 5495 0388 67FF 0B89 1239 D840 4CF0 > 39E2 18D3 4A9E -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFErsVqTPA54hjTSp4RApBDAKC9nlQd45p1UkwM8nD+WGOh+ZLewwCgrX9q DvV9ZNnD3GQjYEtd4DeCR0w= =sguh -----END PGP SIGNATURE----- -- gentoo-user@gentoo.org mailing list
