If there is an update to a package via updates/ then /etc/portage/package.* will get updated too. Since these are under config protect, they simply are left as dotfiles until you run etc-update. This is annoying in the sense that portage will not display that they are updated until the *end* of a merge. This will result in your custom settings ignored and you might not realize it. Steps to reproduce: 1) Set up something in package.use 2) Let that package listing get updated via profile updates/ 3) emerge -av package; see that your custom settings are ignored 4) See that package.use is awaiting a etc-update change. Possible solutions: - Don't CONFIG_PROTECT /etc/portage/package.*{,/*} - Check for /etc/portage/package.*{,/*} updates before a merge?
To reiterate, just now I was wondering why dev-vcs/git was being built without the curl useflag. I thought that this was a default IUSE change or something to the like. As it turns out, the update to package.use was not processed and as such, it ignored my local setting (which I forgot about). Then I saw a update for package.use and it wanted to change dev-util to dev-vcs, I kicked myself as I just merged it twice for no reason.
We can make portage install a file in /etc/env.d to add it to CONFIG_PROTECT_MASK.
This is in the 2.2_rc68 ebuild, but I leave this open until it's in an unmasked version.
(In reply to comment #3) > This is in the 2.2_rc68 ebuild, but I leave this open until it's in an unmasked > version. > I think you meant to add it to the -9999 ebuild too?
(In reply to comment #4) > I think you meant to add it to the -9999 ebuild too? Thanks, I forgot. It's in cvs now.
This is fixed in 2.1.9.
Errr... Aren't package category/name changes notified just after an `emerge --sync`? It's your responsibility to update them immediately, just like any other configuration file update... Most of the files in this directory being completely custom files, it seems quite risky deprotecting it for everyone... And having it unprotected means you do not even know that the package has had a name/category change... And we have to check changelogs or check CONFIG_PROTECT_MASK after each emerge, to be informed of CONFIG_PROTECT_MASK changes... (another problematic change for me was an Udev update adding /etc/udev/rules.d to it, for example...). For information, if not reverted, users can reprotect it by adding/modifying CONFIG_PROTECT_MASK in make.conf, like this: CONFIG_PROTECT_MASK="-/etc/portage" It can be checked using `emerge --info | grep CONFIG_PROTECT_MASK`. There should not be any mention of "/etc/portage" anymore. (Note that from what I remember, adding "/etc/portage" to CONFIG_PROTECT will not work, as, for exact same paths, CONFIG_PROTECT_MASK has the priority -which is unintuitive and not standard, by the way-, and if it didn't change since then, `dispatch-conf` do not even support exceptions to CONFIG_PROTECT_MASK so they would get updated automatically anyway... I still couldn't find the time to report these problems...).
(In reply to comment #7) > then, `dispatch-conf` do not even support exceptions to CONFIG_PROTECT_MASK so > they would get updated automatically anyway... I still couldn't find the time > to report these problems...). In >=portage-2.1.9 dispatch-conf should be fixed, by this commit: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f5e48098ddd114c2448ff0071f4267b3bc4ee880
(In reply to comment #7) > Errr... Aren't package category/name changes notified just after an `emerge > --sync`? It's your responsibility to update them immediately, just like any > other configuration file update... Most of the files in this directory being In some situation it's advantageous to have the moves applied automatically, without having to run etc-update or dispatch-conf. For example, if you replace the portage tree with a new snapshot without running emerge --sync, and then you try to run a dependency calculation. In this case it's advantageous to have the config files automatically updated just before the dependency calculation. > completely custom files, it seems quite risky deprotecting it for everyone... > And having it unprotected means you do not even know that the package has had a > name/category change... Yes, it does seem a little risky. I think it will be safer if we make it insert comments about which moves have been applied.
(In reply to comment #9) > Yes, it does seem a little risky. I think it will be safer if we make it insert > comments about which moves have been applied. It's fixed to add comments here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=7a26634d5d7d02c49dce17b81d8271d509abd4d0
(In reply to comment #9) > In some situation it's advantageous to have the moves applied automatically, > without having to run etc-update or dispatch-conf. For example, if you replace > the portage tree with a new snapshot without running emerge --sync, and then > you try to run a dependency calculation. In this case it's advantageous to > have the config files automatically updated just before the dependency > calculation. > Should be pretty rare for most users though... And there could be some "first run" fatal error in case of modified CONFIG_PROTECT'ed package.* files. And people who do this often may decide to add /etc/portage to CONFIG_PROTECT_MASK, at their own risk. Another idea would be to keep an independent database of past name/category changes, so it does not clutter the tree. They would serve as aliases in command lines and package.* files, but the user will be warned each time it is used, at the end of every `emerge` invocation. Then, to avoid the performance cost and remove the warning, users will be able to empty the database, possibly with a small helper tool, when they have taken notice of any change which may impact them. In addition to this, there would still be automatic editing of package.* files, CONFIG_PROTECT'ed by default. A bit more complex, surely, but this may well be needed. As far as I'm concerned, I really want to avoid any automatic modification of files I created or heavily modified (it is an important reason why I'm using Gentoo), and if not changed, I will simply continue using CONFIG_PROTECT_MASK="-/etc/portage". (In reply to comment #9) > It's fixed to add comments > I was thinking more globally, for example in case of some more important change than name/categories (which can already mess up the file formatting and ordering), including by third parties. For example, I have a custom script in "/etc/portage/postsync.d/eix-update". If some day Eix decides to put one script here with the same name, and I have FEATURES="unmerge-orphans" (activated by default), then Eix will overwrite my script without warning, because it is not CONFIG_PROTECT'ed. I surely do have backups, but I don't keep them indefinitely, and if I don't even notice the change, I may lose my custom script definitively.
(In reply to comment #11) > For example, I have a custom script in "/etc/portage/postsync.d/eix-update". If > some day Eix decides to put one script here with the same name, and I have > FEATURES="unmerge-orphans" (activated by default), then Eix will overwrite my > script without warning, because it is not CONFIG_PROTECT'ed. At least you'll receive an eerror message about the file being ovewritten (and eerror messages are displayed when emerge exits and also logged in /var/log/portage/elog/summary.log). This type of collision error is suppressed for CONFIG_PROTECTed files, but not for CONFIG_PROTECT_MASKed files.
(In reply to comment #0) > Possible solutions: > - Don't CONFIG_PROTECT /etc/portage/package.*{,/*} > - Check for /etc/portage/package.*{,/*} updates before a merge? Even if we keep the CONFIG_PROTECT_MASK=/etc/portage setting as default, for those who choose to negate it, a warning message before dependency calculations would be useful. We could put this check next to the one that checks how long ago your last --sync was.
(In reply to comment #13) > (In reply to comment #0) > > - Check for /etc/portage/package.*{,/*} updates before a merge? > > Even if we keep the CONFIG_PROTECT_MASK=/etc/portage setting as default, for > those who choose to negate it, a warning message before dependency calculations > would be useful. We could put this check next to the one that checks how long > ago your last --sync was. This is in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0c128a031cb9589124e4c3628f3191d419c5518d
As of 2.1.9.3 and 2.2_rc79, the portage ebuild no longer sets CONFIG_PROTECT_MASK=/etc/portage. Instead we have the new warning message mentioned in comment #14.
