From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FyxGh-00037A-58 for garchives@archives.gentoo.org; Fri, 07 Jul 2006 20:49:43 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k67KlM36024014; Fri, 7 Jul 2006 20:47:22 GMT Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k67KYtpo016602 for ; Fri, 7 Jul 2006 20:34:55 GMT Received: by wx-out-0102.google.com with SMTP id t12so1159371wxc for ; Fri, 07 Jul 2006 13:34:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:disposition-notification-to:date:from:reply-to:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=WnH6klf55qBSveNQM5XSqZ6sHeLdb10BL1hnRrHIyDCes1aZhaoHnIxkWe2ZWoLKP4U81/U8uZ6BLx3FsQW8dKQNXXj4gBrWZu6I1i/rrO5S6ZwatpfAN8bDSTXchw024aND9oAhz9LsMXYGPnH73D5WUtYgTOJVGk4v4/EIAqs= Received: by 10.70.128.8 with SMTP id a8mr1024421wxd; Fri, 07 Jul 2006 13:34:54 -0700 (PDT) Received: from ?192.168.0.102? ( [63.207.177.13]) by mx.gmail.com with ESMTP id i11sm9792697wxd.2006.07.07.13.34.52; Fri, 07 Jul 2006 13:34:53 -0700 (PDT) Message-ID: <44AEC56B.70403@gmail.com> Date: Fri, 07 Jul 2006 13:34:51 -0700 From: gentuxx User-Agent: Thunderbird 1.5.0.4 (X11/20060605) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Things that can be improved References: <44AEB475.8000702@maestroprogramador.com> In-Reply-To: <44AEB475.8000702@maestroprogramador.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id k67KlM3N024014 X-Archives-Salt: 9c618ec8-2991-47a3-a8e3-5dd446798439 X-Archives-Hash: c98a7d816c19b3b1164513f0c53fbfd7 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rafael Fern=C3=A1ndez L=C3=B3pez 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" fo= r > 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=C2=A2... > > -- > gentux > echo "hfouvyyAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge' > > gentux's gpg fingerprint =3D=3D> 5495 0388 67FF 0B89 1239 D840 4CF0 > 39E2 18D3 4A9E -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFErsVqTPA54hjTSp4RApBDAKC9nlQd45p1UkwM8nD+WGOh+ZLewwCgrX9q DvV9ZNnD3GQjYEtd4DeCR0w=3D =3Dsguh -----END PGP SIGNATURE----- --=20 gentoo-user@gentoo.org mailing list