Re: [gentoo-dev] gentoo-project

[Martin Schlemmer]

On Mon, 2003-09-08 at 07:33, Jan Krueger wrote:
> 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)
>

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 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
>

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 config
> files, depmod -a, that may be required to do after installing the files to
> the life filesystem.
>

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 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.
> -

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 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.
>

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 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.
>

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,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa