Optional sub-indexing by minor version for packages

E

Erichans

During the three months overlap period of two successive minor versions of supported FreeBSD-RELEASE versions, packages for supported architectures are built only for the soon-to-be-EOL minor version until its final EOL date, after which only the highest minor version of the two is supported (and for which packages are then build). This can be a problem for a small number of packages, especially kernel modules.

Why can't we have an optional sub-indexing by minor version; something like ${ABI}-minor_version? *
Or is this problem with incompatible packages during the three month overlap of a new released FreeBSD minor version something that "doesn't need fixing"?

As I see it, we have the following issues during an overlap period:
  • It affects a significant number of (package) users, new and experienced ones alike
    (seems a recurring topic here on the forums in one form or another).
  • It is rather antithetical to the general objective of planning and executing updates carefully as it "forces" users to wait for a minor version update just until the old minor version goes EOL
    (The only resolve is to resort to building the port(s) in question).
  • IMO it does not help in making FreeBSD more attractive for new users and general use, o.a. desktop oriented users.
    (especially when (graphics) kernel modules are "chasing" current technological updates, be it adapted from Linux or from elsewhere).
  • Looking at the FreeBSD handbook this particular package problem during the overlap period and how to work with or around it isn't addressed or explained.
  • (As far as I know this has nothing to do with the "pkgbase" that is being developed.)

For a solution of "package minor-version sub-indexing", I see the following aspects:
  1. Software development & implementation of adding optional FreeBSD RELEASE minor version sub-indexing to packages.
  2. Identification and tagging of all ports for specific packages that could benefit from this minor version sub-indexing.
  3. Additional temporary** build-time for the overhead of extra packages.
  4. Additional temporary** storage for extra packages.
The temporary** aspect relates to the three months overlap period during the transition period of two successive FreeBSD minor versions. Initially I feared #3 & #4 could be a problem, but based on replies here and there that does not seem an issue. I think the number of packages and storage requirements do double because for each supported minor version you have the quarterly and latest branch.

A solution would result in getting/updating a FreeBSD minor version specific package version when there is one available, for example 13.2-RELEASE versions of graphics/drm-kmod (plus related ports) and emulators/virtualbox-ose-kmod or 13.3-RELEASE versions.

___
* My initial question was here, but I decided to make it a new topic.
 
I would suggest sending your proposal(s) to the mailing lists. Remember that this is a forum for user support by other users. The forums can only provide assistance on FreeBSD as-is. There are very few people around that will be able to do anything regarding the current situation. So all you will get here are a bunch of opinions and nothing would change.
 
You must log in or register to reply here.
Back
Top