| 1 |
On Sat, Jun 20, 2020 at 10:04 PM William Kenworthy <billk@×××××××××.au> wrote: |
| 2 |
> |
| 3 |
> I cant see any |
| 4 |
> advantage to having multiple ebuilds for a package instead of using a |
| 5 |
> support framework to deal with it other than exposing multiple |
| 6 |
> opportunities for things to go wrong and make it harder to fix. This not |
| 7 |
> an elegant design! |
| 8 |
|
| 9 |
Uh, refactoring shared code into modules is generally considered the |
| 10 |
best design. |
| 11 |
|
| 12 |
Generally packages are split up when they are shared, or when they |
| 13 |
have different update cycles or upstreams. The details around the |
| 14 |
splits vary between packages but if you cite and example it probably |
| 15 |
will be easy to explain why that particular example was split. |
| 16 |
|
| 17 |
KDE/Plasma was split up because it makes no sense to rebuild 500 |
| 18 |
binaries when one of them has a security update. |
| 19 |
|
| 20 |
Those account ebuilds were split out because multiple packages could |
| 21 |
require the same group, and this helps ensure the default uid/gid |
| 22 |
doesn't change depending on what order you install packages in. |
| 23 |
|
| 24 |
Packages like systemd/openrc tend to be a little more modular because |
| 25 |
they may require integration with other things and it doesn't make |
| 26 |
sense to replicate that integration across many versions of the |
| 27 |
packages on both sides. |
| 28 |
|
| 29 |
mysql-init-scripts is a separate package because it gets shared |
| 30 |
between mysql and mariadb. This isn't done often, but it does have |
| 31 |
the side benefit that if there is a bug in the init.d script you don't |
| 32 |
have to rebuild the whole database server to get a new bash script. |
| 33 |
|
| 34 |
You have virtual packages because sometimes you want to depend on a |
| 35 |
capability and not a specific package. For example you need an mta to |
| 36 |
be installed but you don't care which one it is, and so as a result |
| 37 |
you see virtuals show up in the install list even though they don't do |
| 38 |
anything. |
| 39 |
|
| 40 |
A fair bit of this comes from Gentoo's flexibility. If we didn't |
| 41 |
support 47 different ways of doing everything it would be much easier |
| 42 |
to create monolithic packages. |
| 43 |
|
| 44 |
In general we tend to find the balance. Plenty of other distros take |
| 45 |
this MUCH further than Gentoo does - though some of this is driven by |
| 46 |
being binary. The same source package works for any arch, but if |
| 47 |
you're doing a binary distro the manpages might work for everybody but |
| 48 |
obviously anything compiled has to be split up by arch. |
| 49 |
|
| 50 |
-- |
| 51 |
Rich |
Archives