Ubuntu Monthly Update Cadence Proposal
list at xenhideout.nl
Thu Feb 1 10:38:35 UTC 2018
Pardon me if my opinion is not worth much here, but I would still like
to offer some five points.
1. The lack of staging in Linux makes it rather hard as mr. Basak points
out, there are few foundations of stable libraries; Linux would need 4
layers of stability in the sense of layer 1 (glibc) remaining stable
over the longest period, layer 2 remaining stable for half that period,
layer 3 for half that, and layer 4 can do whatever it wants.
I mean that if glibc remained stable for 4 years, the next layer for 2
years, the next for 1 year, then layer 2 could depend on layer 1, and
layer 3 could depend on layer 2, and layer 4 could depend on layer 3.
Stability means: no changes in functionality.
2. If any such stability was achieved upstream it would make it easier
to achieve your goal here; it tends to be the case that newest libraries
constantly depend on newest libraries, newer versions breaking older
3. If regardless you accomplish identifying sets, it would lead to my
4. Apt is geared towards advancement, not retreat. Meta packages can't
be used to uninstall, and rarely to downgrade. Any component grouping
would benefit from being real atomic entities that can be removed as a
whole as well.
5. My main point is that components could introduce new apt jargon in
the sense that:
"apt groups" would list all components
"apt list <group>" would list the packages for that component
other apt commands remain the same, but might have slightly
Once this tooling is in place management of these components would
become a lot easier.
Additionally with respect to point 4, I think it is essential that
people can also downgrade to a previous 'Monthly'.
This means that all the library versions of that monthly still have to
be available in the repos essentially creating 'frozen' sets for each
Also, if meta packages (or new "groups") pull in the upgrades they must
be specified on exact versions so that pervious meta packages can
downgrade what was upgraded.
Ie. the meta package "monthly-latest" pulls in "monthly-18.10.4", with
"monthly-18.10.4" pulling in the changes, but "monthly-18.10.3" would be
able to undo all of that.
This would imply that those monthly metas do not only indicate what they
upgrade, but also what they didn't upgrade.
The monthly metas then indicate the exact versions of all core
As an additional colloquium:
Core components might also need to specify ALL libraries being pulled
in by their upgrade, and might require those libraries to be split off
into components of their own if these libraries are shared between core
At the same time this creates inflexibility; you cannot keep using an
older version of udev if it breaks some device.
More information about the Ubuntu-devel-discuss