[arch-general] Why bind-tools was merged into bind package?
eschwartz at archlinux.org
Mon Jul 20 21:05:52 UTC 2020
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. 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.
> 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
> 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
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.
Bug Wrangler and Trusted User
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1601 bytes
Desc: OpenPGP digital signature
More information about the arch-general