Re: [gentoo-dev] suggestion portage ebuild system file modification rights and protection

[Thomas de Grenier de Latour]

On Mon, 8 Sep 2003 02:08:51 +0000
Jan Krueger <jk@×××××××××××.net> wrote:

> On Sunday 07 September 2003 23:41, Jon Portnoy wrote:
> > You haven't explained why it's not sufficient.
> Read again.
>
> > > Again examples from the actual tree, so you can try yourself:
> > > 1. emerge ezmlm and emerge ezmlm-idx
> > > providing slightly different funtionality they will overwrite each
> > > other(instead of blocking each other)
> >
> > Bug. Is it filed?
> Bug in portage! portage is the one that allows such integrity mess.

I vote for the "bug in ebuild". In a recent thread [1] I've posted the
results of a "search for files that belongs to several packages" on my
system, and it's true that there are many such packages (nothing to
worry about in general though). I think what lacks to gentoo developers
(please devs, correct me if I'm wrong) is control mechanism do detect
this kind of overwrites: they don't have all portage packages installed
on their computer, and even if it was the case, portage does makes much
noise about overwritings. Hence they don't detect this kind of bugs, but
they are still package specific.

   Now, to improve this situation I imagine a kind of database of the
different pkg-ver contents. When a dev tests a new ebuild for foo/bar,
he could check against this base that the content of his package won't
conflict with any other already existing package but other versions of
foo/bar (idealy in the same slot). If there are conflicts, then he could
add some blocking dependencies, or rename the files, or decide to accept
the overwrite, and then submit the definitive content of his package
to the database. 

I think in the above mentioned thread, somebody also suggested that
overwritten files (excluding updates) should be archived by portage
for safety (or at the contrary that they should not be merged and would
require the user to explicitly make the overwriting). The idea sounds
good, but his redundant with the above mentioned package content
checking. I don't know what would be the best. I think this second one
is closer to the behavior you expect, but I fear the "yet another task
for emerge" effect which may compromise its speed. And I fear "user
bugs": so many people forget to etc-update after a baselayout upgrade
and then complain, so please, don't give them a "bin-update".

And all this things may be useful from a quality point of view, but
should not be consider as some "security" measures. Overwriting are
often not needed for malicious code be executed by root: puting a file
with the right name in another place of the path (or a library
in /usr/local/lib for instance) will often be enough. We are back to the
'trust ebuilds and devs' situation.

Now about config files: sure things may be done differently, with maybe
a little more control for the user. But in ebuilds I've read so far,
postint commands that modify config files are really not harmful. Who
want to manage by hand scrollkeeper entries or this kind of things? If
you have examples of existing ebuilds with post_install commands that
doesn't feet your needs, I'm sure bug reports will be welcome.

>  changeconf phph.ini "line to add to phpini"

Can be done in src_install: read it, modify it, write it. You will 
have access to anything you really need (grep, sed, etc.), and user will
have to accept the file with etc-update/dispatch-conf. But again, if it
may be justified for php.ini, it is not for an xml catalog or other
ugly things like this, and there the postinst commands are really
handier.


[1] http://article.gmane.org/gmane.linux.gentoo.devel/11630

-- 
TGL.

--
gentoo-dev@g.o mailing list