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