Summary: | >=sys-apps/portage-2.1.10.11 only changes /var/log/portage ownership when upgrading from <sys-apps/portage-2.1.10.11 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jouni Rinne <l33tmmx> |
Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
portage-2.1.10.35.patch |
Description
Jouni Rinne
2011-11-19 11:41:22 UTC
Created attachment 293083 [details, diff]
portage-2.1.10.35.patch
The intention of the existing code is to correct the default permissions one time, when upgrading from <sys-apps/portage-2.1.10.11, and to leave them untouched thereafter. If we remove the has_version call, then it will override the user's permissions during ever upgrade, which is not necessarily desirable. Closing a WONTFIX, since the current behavior is intended, as explained in comment #2. Well, can you then explain why it didn't work when I upgraded from pre-2.1.10.11 to >=2.1.10.11??? It may be that you upgraded to portage-2.1.10.11 before I added the permission changes to the ebuild, which could have happened if you installed ~arch portage between August 12 and 27: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/portage/portage-2.1.10.11.ebuild?view=log#rev1.4 Actually, the first stabilization was on August 26, so some stable users may have updated before I added the permission change to the ebuild. |