Portage feature request - versioning

[neyuru]

I have with the testing keyword ~amd64 four big packages:

1) Libreoffice
2) Texstudio
3) Thunderbird
4) Firefox

Sometimes, a new version shows up but only to have one or two fixes. Eg, there where two fixes from Firefox 92.0.1 vs 92.0.2.

I would love to be able to specify how many revisions are necessary for portage to consider updating that specified package. Something like: emerge every 2 or 3 minor revisions compared to the actual installed package (from X.Y to X.Y+2 or X.Y.Z to X.Y.Z+3). I find it hard to justify a 3+ hours compile time for a fix that hardly affects me in some way.

I know I brought this to myself by accepting testing versions, but it would be nice to have this option. There's already a suggestion in another forum post as to how to handle this, but it is manual labor. Wondering if anyone else would like to have this feature =)

[Hu]

The problem with this approach is that minor revisions may be very important. Consider if Firefox 92.0.3 came out with a single fix for a catastrophically bad security problem that affected everyone. You would want that fix, even though there have not been enough revisions to justify the bump according to your count based rule. Should maintainers adopt some special rule that important security fixes get a multilevel bump to override your attempt to skip minor revisions? Should maintainers just shrug and say that people who skip minor revisions get what they deserve, however bad that is? Should we have some procedure where maintainers push news releases that tell you that you need to stop blocking the update?

I think the better approach would be to have a machine-readable pseudo-changelog, although this would require the maintainers to put more effort into bumps. For example, when a bump comes out, it would include metadata to answer questions such as:

• Are there known security fixes in this release?
• Are there known fixes for high impact bugs (crashes, memory leaks, data corruption)?
• Is this release a no-op for some architectures? For example, if the fix is in an architecture-specific file, some architectures will build an equivalent program before and after. Such architectures would benefit from being able to skip the update.
• Is this release a no-op for some USE flag combinations? For example, if the release improves Wayland support, but I do not use Wayland and have expressed this with USE=-wayland, then I do not need the update.

Given that kind of data, Portage could, according to local rules, selectively skip some updates and apply others.

[Goverp]

Back when I was an IBM mainframe VM system programmer, the patch list was mandatory reading - go through, ticking off the relevant patches, and apply only them. And of course, avoid all even-numbered updates.

Checking all the change logs is probably unreasonable with the enormous number of packages on linux systems; for some packages, skipping even numbered changes makes a sort of sense, though if someone issues two fixes with out development changes between, that fails!

I often skip the first distribution of a new kernel release.
_________________
Greybeard