Summary: | "Upgrade Granularity" to lower the use of package.mask | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Tommie <d00-tga> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Other | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Tommie
2006-06-14 15:30:19 UTC
Unless you're running your servers ~arch, you shouldn't see very many _pre, _alpha, _rc, etc. packages. As for -rX, security-related patches are commonly applied in revbumps. (In reply to comment #1) > As for -rX, security-related patches are commonly > applied in revbumps. Yes. I forgot about security. ;) Anyway, there are two problems with -r? and security: 1) Not all bumps are security related. They can be bugfixes to the ebuild itself. 2) My servers are behind firewalls. This implies; it is important to keep sshd patched, but exim could be years old. Either way, I don't like emerging glibc on production servers. But, if glibc leaps from 2.3 to 2.4, this is probably a major leap and it would be a shame to miss it... I can think of two ways to merge our thoughts: 1) Integration with GLSA. Again, package preferences, which is most important to that user; revdep-problems, security, or having a fresh system. At the user's discretion. GLSA scripts already exist, it's just a matter of telling which packages should be forced under GLSA protection and which are upgraded less frequently. (I insist there is less a chance a security hole in glibc can be exploited, than can it in ssh. Because there are more abstraction and security mechanisms on the way.) 2) Package expiration. Allow the installed package to be two months old, then upgrade it. I actually forgot this in my bug report. (In reply to comment #2) > 1) Integration with GLSA. Again, package preferences, which is most > important For bug 96088, part of the plan is to have a "security" package set that covers security updates. We already have several types of granularity under the existing system: 1) package.mask (as you already mentioned) 1) stable vs. unstable keywords 2) emerge -u vs. emerge -u --deep 3) maintain a list of packages that you would like to explicitly upgrade and feed just that set to emerge (package set support for bug 96088 may include user sets that will simplify this) I'm not sure that the addition of more granularity would provide a significant benefit. I wouldn't recommend for source based updates to be performed directly on a production server. Ideally, the updates will first be tested and then deployed as pre-built binaries. Anything involving version deltas is pretty much impossible IMHO. |