libblockdev - Split all provided plugins into separate packages (motivation?)
All, David, Just did the system upgrade with the split of libblockdev packages, all went fine, though it did suggest install of the LVM plugin. I'm curious as to the motivation for the change? Easier to maintain? Smaller packages? Less overhead? etc... The trend I've seen over the past several years is to subdivide packages, which as long as they continue to work is fine, but at some point it does begin making it harder for the user to keep track of what all subpackages are required for package-X -- unless they are intimately familiar with they package and their use needs. So why was libblockdev put on the chopping-block? -- David C. Rankin, J.D.,P.E.
On Fri, 2024-02-23 at 22:13 -0600, David C. Rankin wrote:
All, David,
... The trend I've seen over the past several years is to subdivide packages, which as long as they continue to work is fine, but at some point it does
... Its an interesting question how best to offer a package - some thoughts to ponder perhaps. The choices are: ------------------ (1) Leave it exactly as provided by upstream. foo means foo. (2) Split upstream 'foo' into smaller chunks where the main package has the same name as upstream (foo) and create new names for sub- packages (foo-sub1, foo-sub2...) (3) Split upstream into smaller chunks with main package named "foo- core" (or similar) and provide a meta package called "foo" which pulls the sub-packages back together. Now 'foo' provides exactly what upstream 'foo' provides. (4) ? Work to use/maintain --------------------- Splitting packages is more work, in general, than keeping a single package for maintainers and users both. So, I suspect part of David et al's motivation may be disk space which may be a potential benefit for some? It is also ongoing work to keep track of upstream developments and their inter-dependencies which may invalidate split packages without making some change(s) to packaging. It is more work for users figuring out which sub-packages may be needed. Again this is ongoing - change a postfix config to use new data store type - better make sure you have the sub-package first. Size Benefits? -------------- Possibly some benefit - is it worth the effort - you be the judge. - linux-firmware is about 1/2 the size of all the linux-firmware-xxx sub packages - a 200 MB saving. Could be relevant for mini machines. - postfix - main package is 4.4 MB and subpackages are each 50kB. size is of very little benefit here. - libblockdev - main package is 3.3 MB and subpackages are 50-100k each. texlive on the other largely follows (3) except the meta package is named texlive-meta instead of just texlive. As a LaTeX user I cannot imagine a user not installing the meta package. Documentation tools, however, like sphinx may only need a subset. Recommendations: ---------------- * Only do (1) or (3). * Only split a package if there is very clear and well documented rationale to do so. For those existing packages currently using (2), I suggest either change to (1) or (3). If (2) is absolutely needed for some reason (I cannot think of one) then provide a meta package (foo-meta, foo- upsteam, foo-all or whatever). Certainly, as a user my expectation installing a package called 'foo' is that it provides all of upstream 'foo'. Unfortunately, there are packages which follow (2) which is the least desirable approach of the 3 choices. Good question. -- Gene
On Sat, Feb 24, 2024 at 07:10:49 -0500, Genes Lists wrote:
- postfix - main package is 4.4 MB and subpackages are each 50kB. size is of very little benefit here.
It's not just about package size, but also dependencies. Before Postfix supported dynamic maps, every build-time dependency (pcre, lmdb, ldap, mysql, postgres, ...) was linked into every postfix binary, so you had to have all of them installed. Dynamically loadable modules allow for cherry-picking of dependencies without breaking the package. Package-wise there are two possible implementations: sub-packages with explicit dependencies, or one main package with optional dependencies. The sub-packages are a bit more cumbersome to deal with, but explicit dependencies are easier to track than optional dependencies... Geert
On Fri, Feb 23, 2024 at 10:13:03PM -0600, David C. Rankin wrote:
All, David,
Just did the system upgrade with the split of libblockdev packages, all went fine, though it did suggest install of the LVM plugin. I'm curious as to the motivation for the change? Easier to maintain? Smaller packages? Less overhead? etc...
Possibly due to the mkinitcpio hooks reorganization [1]? [1] http://tinyurl.com/ms4uspkx Merell --
participants (4)
-
David C. Rankin
-
Geert Hendrickx
-
Genes Lists
-
Merell L. Matlock, Jr.