Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Tue, 12 Sep 2006 10:19:40 +0200 Simon Stelling <blubb@g.o>
> wrote:
> | > Protected Locations
> | > ===================
> | >
> | > Protected locations are determined by the ``CONFIG_PROTECT``
> | > environment variable, which is defined in the profiles and which
> | > may be augmented or overridden by the current environment and user
> | > configuration files. This variable contains a space separated list
> | > of values which are matched against the beginning of a full file
> | > path and name of files to be installed.
> |
> | "which are matched against the beginning of a full file path" would
> | mean that e.g. CONFIG_PROTECT="/etc/foo" would protect the following:
> |
> | /etc/foobar/doh
> | /etc/foo
> | /etc/foobaz
> |
> | .. or did I misunderstand something here? I don't know whether that is
> | the current behaviour of portage, but IMO it certainly shouldn't be.
> | It should rather be
> |
> | /etc/foo (file)
> | or, if /etc/foo is a dir:
> | /etc/foo/*
>
> Mm. I had a play with this. I'd like someone else to do independent
> tests, because I'm seeing something weird here. But it looks like
> Portage's current behaviour is:
>
> with CONFIG_PROTECT="/foo":
> * if /foo is a file, it's not protected
> * if /foo is a directory, its contents (including subdirectories) are
> protected
> * /foofoo (file) is not protected
> * /foobar/baz is not protected
>
> and weirdly, with CONFIG_PROTECT="/foo/"
> * if /foo/ is a directory, its contents are protected during unmerge
> but not during merge
>
> All of this is rather weird, and doesn't match up to what I've been
> told by Portage people that Portage is supposed to do...
>

When I've looked at the relevant code, it's given me the impression
that it could use some improvement.  Frankly, I'm not surprised that
portage's CONFIG_PROTECT handling doesn't behave quite like one
would hope/expect in the cases mentioned above.  Anyway, I'd like to
fix it so that it behaves better in all of those cases.  Note that
bug 14321 already exists for that specific case that Simon has
mentioned.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFBvAU/ejvha5XGaMRAidrAJ9jQfHIHuDLomohU0JURE9f4fwPggCgvmhb
hnnzooKZCwmdDl4mG8wsqIA=
=J3/L
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list