From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5683 invoked by uid 1002); 8 Sep 2003 04:10:13 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 30405 invoked from network); 8 Sep 2003 04:10:11 -0000 From: Martin Schlemmer Reply-To: azarah@gentoo.org To: Jan Krueger Cc: Jon Portnoy , Gentoo-Dev In-Reply-To: <200309080533.05121.jk@microgalaxy.net> References: <200309080454.04214.jk@microgalaxy.net> <20030908030302.GA12215@cerberus.oppresses.us> <200309080533.05121.jk@microgalaxy.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-srF0s64hwvc4WVdADWpU" Message-Id: <1062994416.8455.280.camel@nosferatu.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 08 Sep 2003 06:13:36 +0200 Subject: Re: [gentoo-dev] gentoo-project X-Archives-Salt: 413cfd7a-4d8a-4b2a-85c8-2646194f372a X-Archives-Hash: 450e440740838fdf3fc924c1725f41cf --=-srF0s64hwvc4WVdADWpU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2003-09-08 at 07:33, Jan Krueger wrote: > On Monday 08 September 2003 03:03, Jon Portnoy wrote: >=20 > > You haven't shared many of your views > Here they are again summed up for the interested reader: >=20 > -prevent ebuilds from modifying the life filesystem (from pkg_postinst fo= r=20 > example), portage is the only one allowed to do so. that means a real san= dbox=20 > over full ebuild time. the image is ready after src_install. portage than= =20 > puts the files at the right place. The ebuild itself can in no way touch = the=20 > live filesystem. there is no need for the ebuild to do so. > (putting the build system into UML would be a considerable option for thi= s.=20 > maybe oversized) >=20 This is not always possible as I have said before. Mozilla for instance have many issues if you do not remove the old chrome files and registry to name one. Another is baselayout that is in general a pita. > -allow the actual package install process only to add files to the filesy= stem=20 > or to only modify/remove files that belong to an revision of the same ebu= ild > (qa would benefit from this suggestions too.). Portage, before putting al= l the=20 > files from the image into the life filesystem, scans the image for all fi= les=20 > in there. now it has a list of files it is going to install. So it=20 > scans now the live filesystem if thes files, or some of them exist. If th= ey=20 > exist in the live filesystem, portage checks if they belong to a revision= of=20 > the same ebuild. > -if they dont belong to a revision of the same ebuild and are not found = in=20 > the live filesystem it would be an addition of new software so the files = are=20 > put into action > -if they are found in the filesystem and belong to a revision of the sam= e=20 > ebuild it would be an upgrade or downgrade and are put into action > -if they are found in the filesystem and do not belong to a revision of = the=20 > same ebuild -> something is wrong (might be init going to be overwritten)= ->=20 > inform the user and fail >=20 This might be an good idea, but it will slow down things a lot. This is Nick's (carpaski) domain, so we will have to check with him. > -provide an secure abtraction for things, like adding values to global co= nfig=20 > files, depmod -a, that may be required to do after installing the files t= o=20 > the life filesystem. >=20 Its not often that this is really done. The only places, this was done with some care (look at pshadow and pam-login for examples), and a backup, etc was made ... > >From my answer to Jon: > > So we should never be able to tweak config files et al in an ebuild? > an ebuild may freely modify its own config files. > modification of config files not belonging to the ebuild should be done v= ia an=20 > already suggested, secure abstraction, lets say a function like: > changeconf phph.ini "line to add to phpini" > portage could then intercept, respecting the suggested CONFIG_EXCLUDE or = other=20 > user settings, or, if no user setting is the way, go to apply the change. > This way it would be impossible for the ebuild to wipe php.ini. > Also the user, via CONFIG_EXCLUDE, may completely switch of editing of ph= p.ini=20 > by ebuilds. On the other hand, if the user doesnt care, the ebuild is fre= e to=20 > add this line to php.ini. > - As said above .. its not often that you really need to hack the config files. The docbook/xml/sgml stuff may be another not so common example where it is best to do it without user interaction. > another one was the above mentioned > CONFIG_EXCLUDE in /etc/make.conf: > This variable would accept a list of directories/files for which the beha= viour=20 > of portage would be like follows: > whenever portage has the image of the to install software ready it scans = this=20 > image for the values in CONFIG_EXCLUDE. > whenever it finds such a directory/file in the image it moves the=20 > directory/file to the doc-directory (eg:=20 > /usr/share/doc/${PF}/excluded_config/ ) of the image (and maybe writes a=20 > message to the user/log) > after that portage continues normally. >=20 As I said in a previous mail, the CONFIG_EXCLUDE feature may come in handy, and will solve the make.conf issue for one. > > repeated yourself without elaborating or expressing > > specific concepts. > If, in your eyes, above things arent concepts and specific i dont know wh= at=20 > else actually is. I dont understand you, you dont understand me, so thats= the=20 > wrong place for me, i quit. >=20 > I always tried to be strictly technical, maybe sometimes i failed. i am h= uman. > Sorry. Dont hate me, i, as you, only try to do my best. >=20 Relax, just do not be so pushy from day one. Try to find out more first. Maybe try to create a few ebuilds, or try to update some. Maybe have a look at some open bugs, and try to help fix them. Alternatively you might try to have a look at the portage code. Basically, get involved, see how things is done (not a objective view from the outside without having been involved first). Then recheck what you think, and bring it to the table with enough why's and why not's. Regards, --=20 Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa --=-srF0s64hwvc4WVdADWpU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/XAHwqburzKaJYLYRAlaaAJ9z4UIXyjfpYDSjp6/mqK7c4ABOqACeKwZL 7G1t4RS6DQaPl70O1PkdZh0= =+NYv -----END PGP SIGNATURE----- --=-srF0s64hwvc4WVdADWpU--