Hi all! I have a couple of slower servers running now. My goal is to do an "emerge world" once a month... However, I don't like emerging the *big* packages (gcc, glibc, x11) or application critical (exim, mysql) at every "-r?" release level of the ebuilds. For now, people use /etc/portage/package.mask to tell portage to not emerge a new version temporarily. My suggestion is to add a new file "package.granularity" (Granularity was just the first word that struck my mind...) The format of the file would be something like sys-libs/glibc-0.1 mail-mta/exim-0.10 this, of course, is to be coherent with the other package.* files. The meaning would be to tell Portage to skip upgrades iff the version increments are lower than the given. So a glibc-1.2.3 would not be upgraded to 1.2.5, but to 1.3.4. Exim would not upgrade 4.60 to 4.62, but to 4.70. My suggestion is to allow granularities down to "-r?", but ignore "_alpha" etc. This is the functionality I would like to see. The package masks gives me a headache, and they are not really what I want. :( Another per-package option is whether to upgrade a package (A) if required by another package (B), or just skip emerging package B altogether. Once again, to avoid application critical failures and/or wasted CPU cycles. This would also be the place to force Portage to use an overlay for certain packages. If I do a site-specific bug fix for a package, it would be bad if the overlay is ignored just because a newer version is available in Portage. (Indeed, this can be fixed by simply renaming the package out of the way, but while I'm at it...) Would this break any basic concept of Portage? Does anyone else want the same thing, or am I just a sysadmin chicken?
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.
