Re: [gentoo-dev] gentoo-project

[Jan Krueger]

On Monday 08 September 2003 03:03, Jon Portnoy wrote:

> You haven't shared many of your views
Here they are again summed up for the interested reader:

-prevent ebuilds from modifying the life filesystem (from pkg_postinst for 
example), portage is the only one allowed to do so. that means a real sandbox 
over full ebuild time. the image is ready after src_install. portage than 
puts the files at the right place. The ebuild itself can in no way touch the 
live filesystem. there is no need for the ebuild to do so.
(putting the build system into UML would be a considerable option for this. 
maybe oversized)

-allow the actual package install process only to add files to the filesystem 
or to only modify/remove files that belong to an revision of the same ebuild
(qa would benefit from this suggestions too.). Portage, before putting all the 
files from the image into the life filesystem, scans the image for all files 
in there. now it has a list of files it is going to install. So it 
scans now the live filesystem if thes files, or some of them exist. If they 
exist in the live filesystem, portage checks if they belong to a revision of 
the same ebuild.
 -if they dont belong to a revision of the same ebuild and are not found in 
the live filesystem it would be an addition of new software so the files are 
put into action
 -if they are found in the filesystem and belong to a revision of the same 
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 
same ebuild -> something is wrong (might be init going to be overwritten) -> 
inform the user and fail

-provide an secure abtraction for things, like adding values to global config 
files, depmod -a, that may be required to do after installing the files to 
the life filesystem.

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 via an 
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 
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 php.ini 
by ebuilds. On the other hand, if the user doesnt care, the ebuild is free to 
add this line to php.ini.
-
another one was the above mentioned
CONFIG_EXCLUDE in /etc/make.conf:
This variable would accept a list of directories/files for which the behaviour 
of portage would be like follows:
whenever portage has the image of the to install software ready it scans this 
image for the values in CONFIG_EXCLUDE.
whenever it finds such a directory/file in the image it moves the 
directory/file to the doc-directory (eg: 
/usr/share/doc/${PF}/excluded_config/ ) of the image (and maybe writes a 
message to the user/log)
after that portage continues normally.

> repeated yourself without elaborating or expressing
> specific concepts.
If, in your eyes, above things arent concepts and specific i dont know what 
else actually is. I dont understand you, you dont understand me, so thats the 
wrong place for me, i quit.

I always tried to be strictly technical, maybe sometimes i failed. i am human.
Sorry. Dont hate me, i, as you, only try to do my best.

Have a nice time

Jan


--
gentoo-dev@g.o mailing list