[arch-general] Why bind-tools was merged into bind package?

[Eli Schwartz]

On 7/20/20 4:51 PM, Sam Mulvey wrote:
> 
> On 7/20/20 1:34 AM, brent s. wrote:
>> Because the binaries formerly known as "bind-tools" are a part of BIND9
>> proper[0]. Upstream, by including "bind-tools" binaries in the source
>> for the BIND9 daemon, ipso facto*intends*  them to be built (and thusly
>> packaged) together. To do so otherwise is - one can make the argument -
>> *not*  The Arch Way[1].
> 
> I don't think that's a strong argument for software that is seen (among
> other things) as a reference implementation, which ISC software often
> is.  If that's the main reason for wrapping the two packages together I
> would rethink it.   This seems like shifting complexity rather than
> adding to simplicity, so bringing up The Arch Way isn't entirely
> appropriate.
> 
> That said, I don't really have a problem with bind-tools being wrapped
> into bind.   Heck, I'm for getting rid of the *-headers packages for
> kernels, but I doubt that'll be implemented anytime soon.

The Arch Way discusses the topic of package splitting:

> Packages are only split when compelling advantages exist, such as to
> save disk space in particularly bad cases of waste.

This is an extremely accurate description of the kernel *-headers,
weighing in at 119.67 MiB compared to the actual kernel's more modest
75.81 MiB.

The general rule is if there is one source archive that builds two
things in one "./configure && make && make install", it per default
makes sense to ship them together. Saving the vast majority of users
100+ MiB of things they don't need is sufficient grounds to split them out.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20200720/f562538d/attachment.sig>