Every time I emerge the new version of bash_completion, I have to etc-update and move the new version in to place. I'd much rather be able to add /etc/bash_completion to CONFIG_PROTECT_MASK and have the file over-written automatically each time while still PROTECTing the rest of /etc. Should be straight forward. Is there any down-side?
No. That would be a major performance hit when merging and unmerging. Maybe it could be implemented later with some fancy caching and matching logic, but not in the immediate future. It would be messy to do so presently anyway as not all packages specify a '/' after the directory and thus would be a source of confusion. If implemented it will be for a seperate variable.
blah
ok, I'll bite. What does "blah" mean? ;-)
Vapier has ebuilds that depend on this. Apparently I was conscious when closing this, as it was supposed to be a 'wontfix'.
For the case at hand, wouldn't it make more sense for bash_completion to install in /usr/share instead of /etc ? It isn't actually a config file.
Bug 9176 ... basically, bash_completion is going to stay in /etc/
*** Bug 32927 has been marked as a duplicate of this bug. ***
*** Bug 40884 has been marked as a duplicate of this bug. ***
Hi, just digged myself through the portage code and came up with the attached solution. Patch is against 2.0.50-r1. CONFIG_PROTECT_FILES and CONFIG_PROTECT_FILES_MASK take precedence over CONFIG_PROTECT and CONFIG_PROTECT_MASK. Performance is still fine from my side. Did several (un)merges of app-office/openoffice with various CONFIG_PROTECT* settings on /opt/OpenOffice* Things that still need to be done: - update equery from app-portage/gentoolkit to allow query of CONFIG_PROTECT_FILES(_MASK) - update etc-update to handle protected files (thinking about rewriting it in python) - Testing ;)
Created attachment 25352 [details, diff] portage-2.0.51-r1-CONFIG_PROTECT_FILES.patch
*** Bug 99744 has been marked as a duplicate of this bug. ***
replying here, carried on from http://bugs.gentoo.org/show_bug.cgi?id=99744 >> /etc/services > >Don't know what's so critical about this one... Some ebuilds also need to >install additional entries there. Yes, this is part of the problem. /etc/services is a real pain to manage if there are a large number of site-local modifications (eg. from installed ebuilds), and baselayout pushes out a new /etc/services - *without* the modifications made by said ebuilds. I can't seem to reproduce this particular bug right now, but I'll see about reproducing it later.
I'm not seeing the bug here. Can someone summarize it please?
(In reply to comment #13) > I'm not seeing the bug here. Can someone summarize it please? >
Created attachment 96837 [details, diff] protect files for portage-2.1.1 This patch fixes the ConfigProtect class so that it properly accounts for config protected/masked files. In addition, it does a couple more things: 1) properly accounts for an optional trailing / on directory paths 2) prevents /etc/foo from matching /etc/foobaz or /etc/foobaz/bar I've created this patch in response to "RFC: Package Manager Specification: configuration protection" discussion of the -dev mailing list: http://thread.gmane.org/gmane.linux.gentoo.devel/42270
Created attachment 96850 [details, diff] protect files for portage-2.1.1 This updated patch fixes the merge phase so that it properly protects or masks single files.
Created attachment 96915 [details, diff] make emerge scan for individual files This adds support to emerge so that it scans for updates to individual files listed in CONFIG_PROTECT. Config update tools such as etc-update and dispatch-conf will need to be modified to support this as well.
Created attachment 97005 [details, diff] etc-update support for individual files
Created attachment 97009 [details, diff] dispatch-conf support for individual files This patch completes portage support for individual files in CONFIG_PROTECT and CONFIG_PROTECT_MASK.
This is in svn r4457:4461.
This has been released in 2.1.2_pre1.
*** Bug 152579 has been marked as a duplicate of this bug. ***
