[arch-general] Why bind-tools was merged into bind package?
I can understand that packagers want to make things easy, but not in this case. I cannot have a full service installed with a new user created, only host, dig and nslookup commands. The splitted package bind and bind-tools had this option, but now I must install a service that I do not need which is annoying. There is any way to reconsider this? Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Seconding this request, bind and bind-tools should stay splitted.
??scar Garc??a Amor via arch-general <arch-general@archlinux.org> wrote:
I can understand that packagers want to make things easy, but not in this case. I cannot have a full service installed with a new user created, only host, dig and nslookup commands. The splitted package bind and bind-tools had this option, but now I must install a service that I do not need which is annoying.
There is any way to reconsider this?
Greetings. -- ??scar Garc??a Amor | ogarcia at moire.org | http://ogarcia.me
If you want only host, dig and nslookup, can't you leave the named service disabled? Or am I totaly misunderstanding you?
On 7/19/20 3:15 PM, Óscar García Amor via arch-general wrote:
I can understand that packagers want to make things easy, but not in this case. I cannot have a full service installed with a new user created, only host, dig and nslookup commands. The splitted package bind and bind-tools had this option, but now I must install a service that I do not need which is annoying.
There is any way to reconsider this?
Why do you care if a service is installed, if you aren't using that service? Don't enable the service. You have lots of disabled services installed already. Why is it a problem if a system user is created that you don't need? You have lots of system users you don't use, already. If it bothers you that much, create a sysusers.d dropin override to prevent that user's creation. I see no rationale to re-split the package. The arguments you're using aren't arguments which arch typically values. -- Eli Schwartz Bug Wrangler and Trusted User
Hi Eli, El lun., 20 jul. 2020 a las 0:11, Eli Schwartz via arch-general (<arch-general@archlinux.org>) escribió:
Why do you care if a service is installed, if you aren't using that service? Don't enable the service. You have lots of disabled services installed already.
So so... :-)
Why is it a problem if a system user is created that you don't need? You have lots of system users you don't use, already. If it bothers you that much, create a sysusers.d dropin override to prevent that user's creation.
No. Maybe the mail, ftp and http but the rest have a lot of sense to me. But thanks for the tip of sysusers.d, I don't know that making a symlink to /dev/null in /etc/sysusers.d with the same name of the file in the package you can prevent user creation. :-)
I see no rationale to re-split the package. The arguments you're using aren't arguments which arch typically values.
The problem is. Where is the limit? The whole distribution in one package? The argument is the same, if you don't need it simply don't use it. In this case we are talking about binaries widely used that will be installed with a service rarely used. I think that packages that have enough entity to be splitted should do it. From my point of view is safer don't have a service installed than installed an disabled. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On Mon, 20 Jul 2020 09:15:47 +0200, Óscar García Amor wrote:
The problem is. Where is the limit? The whole distribution in one package? The argument is the same, if you don't need it simply don't use it.
No it is not the same! Not splitting software provided by a single upstream source into several packages, is not the same as merging different upstream sources into one package. Take a look at the source array of bind. It's one source address, it does not merge software from different sources to a single package, it's just not splitting software provided by one source into several packages. Btw. you could use /etc/pacman.conf's NoExtract array to not install unwanted files.
Responses inline. On 7/20/20 03:15, Óscar García Amor via arch-general wrote: (SNIP)
The problem is. Where is the limit? The whole distribution in one package? The argument is the same, if you don't need it simply don't use it.
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]. Sure, split packages are a thing, but they can get messy and are a bit more of a pain to maintain. Simplicity, being a core value of Arch, prefers monolithic packages where reasonable and sensible. I think this is plenty sensible. There are more tools to investigate DNS than host, dig, nslookup. What you probably want is ldns[2] for your specific use cases. Alternatively, you can write your own tools -i.e. [3a][3b]) that do and behave *exactly* as you want them to, with no extra frills which leaves your install even more minimal than bind-tools would have. You can also, of course, modify the PKGBUILD[4a] for bind yourself, use it to build a split package, and then even add it to your own repository[4b] if you feel that keeping them separate packages is superior. You have a lot of options to make your system behave exactly how *you* want it to without requesting Arch to change *its* design decisions.
In this case we are talking about binaries widely used that will be installed with a service rarely used. I think that packages that have enough entity to be splitted should do it. From my point of view is safer don't have a service installed than installed an disabled.
Greetings.
See again the Arch Way[5]. Arch promises simplicity; it does not promise appeal to masses. Exploiting a service that is installed but not running (as unlike many other distros, Arch does not automatically enable/start a service upon installation) requires access to the machine in the first place. A vulnerability in bind's daemon, at that point, is going to be much less a concern than the attacker actually having arbitrary execution privileges on your box at that point in time, I'd reckon. [0] https://gitlab.isc.org/isc-projects/bind9 [1] https://wiki.archlinux.org/index.php/Arch_Linux#Simplicity [2] https://www.archlinux.org/packages/core/x86_64/ldns/ [3a] https://www.dnspython.org/ [3b] https://www.archlinux.org/packages/community/any/python-dnspython/ [4a] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... [4b] https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Custom_local_rep... [5] https://wiki.archlinux.org/index.php/Arch_Linux#User_centrality -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
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. -Sam
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
On 7/20/20 3:15 AM, Óscar García Amor wrote:
The problem is. Where is the limit? The whole distribution in one package? The argument is the same, if you don't need it simply don't use it.
Don't be facetious.
In this case we are talking about binaries widely used that will be installed with a service rarely used. I think that packages that have enough entity to be splitted should do it.
There is already a distribution which caters to this thing that you think. Its name is Debian. You are free to use it, if you like, however, you are wasting your time trying to convince anyone on this list to tear down one of the core values of the Arch Way. Please read or reread https://wiki.archlinux.org/index.php/Arch_Linux#Principles
From my point of view is safer don't have a service installed than installed an disabled.
You have a right to that opinion. However, if you intend to convince anyone *else* that this is indeed the case, you will need to do more than merely state your point of view. Specifically, you will need to prove it. -- Eli Schwartz Bug Wrangler and Trusted User
El lun., 20 jul. 2020 a las 15:25, Eli Schwartz (<eschwartz@archlinux.org>) escribió:
On 7/20/20 3:15 AM, Óscar García Amor wrote:
The problem is. [...]
Don't be facetious.
It's only a joke, don't take me seriously.
In this [...] safer don't have a service installed than installed an disabled.
You have a right to that opinion. However, if you intend to convince anyone *else* that this is indeed the case, you will need to do more than merely state your point of view. Specifically, you will need to prove it.
The truth is that my arguments are those, simplicity and security. Is true that I can rebuild package or add some configurations to avoid user creation or file installations, but I'm thinking in less advanced users. Anyway if you think that "this is the way" (Mandalorian dixit) I cannot argue anything else and I accept the decision. Greetings -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On 7/20/20 2:15 AM, Óscar García Amor via arch-general wrote:
The problem is. Where is the limit? The whole distribution in one package? The argument is the same, if you don't need it simply don't use it.
If you read the git-commit regarding the change, the packages were combined because there is no longer any significant install size saving splitting the package. The libraries used by the bind-tools apps (1.7M) is not 8X larger than the dns daemon (0.2M) so it no longer made sense to split the package from a size-saving standpoint: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/bind&id=c688d695dc4e82aad9a7ec546bc47e4b5fe5c447 -- David C. Rankin, J.D.,P.E.
participants (8)
-
brent s.
-
David C. Rankin
-
Eli Schwartz
-
Josef Miegl
-
Ralf Mardorf
-
Sam Mulvey
-
u34＠net9.ml
-
Óscar García Amor