Summary: | emerge overwrites files in CONFIG_PROTECT if ROOT != / | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Georgi Georgiev <chutz+bugs.gentoo.org> |
Component: | Core - Configuration | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | critical | CC: | dberkholz, Martin.vGagern, sascha-gentoo-bugzilla |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
config-protect-root.patch
foo-1.ebuild |
Description
Georgi Georgiev
2004-05-29 22:24:29 UTC
OK, here is a much easier way to reproduce the bug: 1. Create a new ebuild in overlay; e.g, here I have $ cat /usr/portage-chutz/test-test/foo/foo-1.ebuild SRC_URI="" LICENSE="GPL-2" SLOT="0" KEYWORDS="x86" DEPEND="" #RDEPEND="" src_compile() { einfo "No compilation" } src_install() { dodir /etc date > "${D}/etc/test-config-protect" } 2. emerge foo-1.ebuild 3. edit /etc/test-config-protect and change it # Checkpoint 1 4. emerge foo-1.ebuild again 5. mkdir -p /mnt/test 6. mount --rbind / /mnt/test # this needs kernel 2.6? 7. edit /mnt/test/etc/test-config-protect # Checkpoint 2 8. ROOT=/mnt/test/ emerge foo-1.ebuild Actual results: At step 4 the file is preserved, but at step 8 it isn't. Espected results: The file is preserved at both steps 4 and 8. Georgi, have you experienced this w/ portage-2.0.51_pre1* at all? I haven't tried the still hardmasked 2.0.51 series. And I will not be able to try until the 22nd of September. It'll still happen, I do believe. Portage makes the assumption that if you're installing into a new root, then you're building a system and shouldn't bother with config protection. It's not documented either way, so it's undefined behavior. The current behavior was probably hashed out to suit catalyst. Different Outlooks: "My System" aka "ROOT=/" "New System" aka "Non-/ ROOT" "Alternate Root" aka "chroot" You are in the "New System" assumption. Just to confirm that this behavior is still in 2.0.51. I am pretty sure that there was either a bug or a discussion, but has it been considered to add this Alternate Root behavior? Was this (New Root) really intentional (to suit catalyst), because after looking at the code it does seem more like a bug. I did some very simple changes to portage.py to implement an Alternate Root outlook like this: 1. I moved the system imports to the beginning of the file. 2. I moved the os.environment.has_key["ROOT"] check after these imports 3. I added this: if os.environ.has_key("CHROOT"): CHROOT = root else: CHROOT = "/" 4. I changed some of the constants that followed to be prefixed with CHROOT+. This way the configuration files are also read from the ROOT path. 5. Up to here, I have portage read all configuration (/etc/make.conf, profile etc) from ROOT. Now for the config protection Looking at dblink.updateprotect I see this: for x in string.split(self.settings["CONFIG_PROTECT"]): ppath=normalize_path(self.myroot+x)+"/" if os.path.isdir(ppath): self.protect.append(ppath) In other words, the config protect directory list contains paths prefixed with myroot. However, in dblink.mergeme we have the following code: offset=stufftomerge mytruncpath="/"+offset+"/" myppath=self.isprotected(mytruncpath) However, stufftomerge doesn't come with a myroot prefix, and therefore myppath checks if a path WITHOUT the myroot prefix exists in the config_protect list of paths that are prefixed with myroot. I changed the invocation if isprotected to pass a parameter prefixed with self.myroot, changed all invocations of new_protect_filename to use "mydest" instead of "myrealdest", because I was getting ._cfg* files in /etc instead of $ROOT/etc and it all seemed to work just as I expected for an Alternate Root. So what do you think? I am not attaching the patch, because it was just proof of concept. I am sure a portage dev can do the job better than me. If you say it's worth it, I'll clean it up, make it backwards compatible (to actually introduce the new behavior *only* when CHROOT is set) and submit it. As I elaborated upon at http://article.gmane.org/gmane.linux.gentoo.devel/26328 , I disagree with this assumption. People may want to maintain systems in a ROOT, not just create them. Created attachment 53496 [details, diff]
config-protect-root.patch
Since the bug has woken up, here is a patch for your testing pleasure. This one
will make portage use the full path (prefixed with ROOT), when merging
config-protected files. I tested various combinations and it seems to work
fine.
Created attachment 53497 [details] foo-1.ebuild A dummy ebuild to test the config-protect patch. Put it somewhere in your overlay: for example $PORTDIR_OVERLAY/app-text/foo. Apply the patch from attachment #53496 [details, diff] and test with: emerge foo emerge foo ROOT=/tmp/dummydir emerge foo ROOT=/tmp/dummydir emerge foo The commands will hopefully behave as expected. As Nick said, there are two perspectives about ROOT - but let's forget those. Let's just look at documentation. CONFIG_PROTECT = [space delimited list of dirs] All directories that are defined here will have "config file protection" enabled for them. For more information, please see `emerge --help config`. ROOT = [path] Use ROOT to specify the target root filesystem to be used for merging packages or ebuilds. Typically, you should set this setting in the environment rather than in /etc/make.conf itself. It's typically used for creating new build images. Defaults to /. Nowhere does it say that CONFIG_PROTECT will magically be enhanced with ROOT's counterparts. Therefore there is no bug as far as incorrect behaviour goes. If you're talking a feature enhancement, I still say WONTFIX - or DUPLICATE of iggy's "separate config for root" bug. If CONFIG_PROTECT is automatically enhanced with ROOT's counterparts, there'll be a counterpart to this bug where somebody *didn't* want CONFIG_PROTECT for ROOT and so set it to -* and then had some required build-time packages installed to /. If you want some of your ROOT config protected, add the directories to CONFIG_PROTECT. When the alternate config bug is fixed, config protection will be part of it. *** Bug 83289 has been marked as a duplicate of this bug. *** A separate CONFIG_PROTECT for $ROOT will likely appear when bug #40302 is implemented. |