[gentoo-portage-dev] kernel drivers vs. portage

[Drake Wyrm]

On Fri, Jan 02, 2004 at 12:31:46AM -0700, in <1073028705.11194.66.camel@×××××××××××××××××××××.net>, Scott Taylor <security@××××××××××××××.com> wrote:
> Perhaps there could be a way for an ebuild to mark a file as one that is
> allowed to be overwritten but not backed out? That might even be able to
> be done by making portage "forget" the timestamp of a kernel module
> whenever its installed. Since the timestamp wouldn't match what is on
> the disk, it wouldn't delete it, but the next emerge could overwrite
> it...
It occurs to me that this would be a great extension of Portage's config-protect features. I've been giving this some serious (if somewhat armchair-quarterback) thought. And now, the "There oughtta be a way..." portion of our show!

Currently, metadata is maintained regarding which files were installed by which packages. An additional set of metadata could be maintained regarding which packages "own" installed files. Rather than relying on mtimes and directories (which could be viewed as a simple claim of ownership), allow ebuilds to install files with properties which control how ebuilds interact in the live filesystem. Altogether, these ideas are very close to the status quo with some improvements in structure.

* "World" Any ebuild may clobber a World file; largely the way things work right now, ergo any file installed without specific properties is assumed to be World file; Portage may or may not referee; most appropriate where other mechanisms of fair play exist (e.g. /usr/share/doc, where each ebuild installs into its own directory; /usr/share/application-registry, again regulated by well-chosen namespace)
* "System" Any ebuild may clobber a System file with another system file, but not with a World file; Portage will not remove a System file until the last ebuild which claims it is uninstalled
* "Config" An ebuild may only clobber its own Config files, but are always free to do so; slots play into this one; Portage referees
* "Protected" An ebuild may only clobber its own Protected files, and only if they have not been modified since installation; this is analogous to the current config-protect system with etc-update administrative intervention; Portage will never overwrite or delete a Protected file

The next, and possibly most (important|difficult|confusing), part of my idea is the ability of ebuilds to defer to other specific ebuilds. Rather than masking between ebuilds that overlap in function, or always blocking a portion of one install to prevent conflict, arrange for one ebuild to defer to its better-suited counterpart. The deferring ebuild will not clobber its counterpart's System files (even though it otherwise could) and the deferred-to ebuild will be able to clobber its counterpart's Config files (even though it otherwise couldn't).

Other random possibilities include allowing ebuilds to tag a file as System, Config, or Protected without trying to replace it. This would prevent a loss of functionality which, though not sufficient for a DEPEND, could be crippling if suddenly ripped out from a configured system.

Truth-be-told, I come nowhere near the required ability for implementing something like this, nor is this a finished concept/proposal. However, it's on the table; rip it to shreds.

-- 
Batou: Hey, Major... You ever hear of "human rights"?
Kusanagi: I understand the concept, but I've never seen it in action.
  --Ghost in the Shell

--
gentoo-portage-dev@g.o mailing list