Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 136827 - "Upgrade Granularity" to lower the use of package.mask
Summary: "Upgrade Granularity" to lower the use of package.mask
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Other
: High normal (vote)
Assignee: Portage team
Depends on:
Reported: 2006-06-14 15:30 UTC by Tommie
Modified: 2006-06-15 11:23 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Tommie 2006-06-14 15:30:19 UTC
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


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?
Comment 1 Andrew Gaffney (RETIRED) gentoo-dev 2006-06-14 15:33:45 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.
Comment 2 Tommie 2006-06-14 16:05:51 UTC
(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.
Comment 3 Zac Medico gentoo-dev 2006-06-14 16:28:36 UTC
(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.
Comment 4 Marius Mauch (RETIRED) gentoo-dev 2006-06-15 11:23:48 UTC
Anything involving version deltas is pretty much impossible IMHO.