Re: libblockdev - Split all provided plugins into separate packages (motivation?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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





[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux