From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14751 invoked from network); 2 Jan 2004 10:17:53 +0000 Received: from smtp.gentoo.org (128.193.0.39) by eagle.gentoo.oregonstate.edu with DES-CBC3-SHA encrypted SMTP; 2 Jan 2004 10:17:53 +0000 Received: from lists.gentoo.org ([128.193.0.34] helo=eagle.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.24) id 1AcMNN-00030U-9P for arch-gentoo-portage-dev@lists.gentoo.org; Fri, 02 Jan 2004 10:17:53 +0000 Received: (qmail 32414 invoked by uid 50004); 2 Jan 2004 10:17:50 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 11040 invoked from network); 2 Jan 2004 10:17:48 +0000 Date: Fri, 2 Jan 2004 02:23:15 -0800 From: Drake Wyrm To: gentoo-portage-dev@lists.gentoo.org Message-ID: <20040102102315.GA28754@phaenix.haell.com> Mail-Followup-To: gentoo-portage-dev@lists.gentoo.org References: <1073027790.3678.24.camel@big_squirt.dol-sen.ca> <1073028705.11194.66.camel@Star.BerthoudWireless.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1073028705.11194.66.camel@Star.BerthoudWireless.net> X-Files: The truth is out there X-Arch: athlon_tbird-gentoo-linux-gnu X-Banner: This space for rent X-Fnord: There is no conspiracy X-Carnivore: bomb taliban infidel saddam hussein osama bin laden george dubya bush anthrax metallica grateful dead america iraq afganistan montana User-Agent: Mutt/1.5.4i-ja.1 Subject: [gentoo-portage-dev] kernel drivers vs. portage X-Archives-Salt: 1c5e7bf0-f492-4a14-9407-3f45e7453fdd X-Archives-Hash: 29ef4b4e7b9e44acb04b3609c8b4f8d4 On Fri, Jan 02, 2004 at 12:31:46AM -0700, in <1073028705.11194.66.camel@Star.BerthoudWireless.net>, Scott Taylor 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@gentoo.org mailing list