bind-tools bloat

[darkphader]

net-dns/bind-tools-9.16.50 did not require the full bind server net-dns/bind which is the case for the upgrade to net-dns/bind-tools-9.18.0, seems like a lot of bloat when one just wants the dig tool, I'm hoping that's just a mistake in the ebuild. Maybe I'll have to get used to using a different tool for the purposes I use dig for.

[freke]

I switched to the eras-overlay for net-dns/bind - it's on 9.20 and bind-tools doesn't require net-dns/bind there.

[dmpogo]

As I see 9.18.0 is unstable and also have extremely simplistic ebuild relative to 9.16 version (basically, single RDEPEND=bind). I hope they will still do work to make it a standalone tool as before

[Hu]

As I read the git log output for net-dns/bind-tools, it is not a mistake. Commit net-dns/bind-tools: add 9.18.0 reads:

Code: Select all

    net-dns/bind-tools: add 9.18.0

    This is just a proxy for net-dns/bind. Splitting the ebuilds is *way* too
    fragile and gains nothing because the same software gets built again anyway,
    just thrown away at the end.

[dmpogo]

As I read the git log output for net-dns/bind-tools, it is not a mistake. Commit net-dns/bind-tools: add 9.18.0 reads:

Code: Select all

    net-dns/bind-tools: add 9.18.0

    This is just a proxy for net-dns/bind. Splitting the ebuilds is *way* too
    fragile and gains nothing because the same software gets built again anyway,
    just thrown away at the end.

That is bizarre, yes bind-tools uses the same tarball, but what is installed at the end is quite different. You do not have any .h include files, not libraries, any init.d scripts polluting startup, no daemons (which can be launched accidentally). What are they talking about ?
Result matters more than how the compilation goes. Utilities are not daemons

[Anon-E-moose]

For the dig utility, I would use the old version, it's not like it needs to be constantly updated.

[pingtoo]

As I read the git log output for net-dns/bind-tools, it is not a mistake. Commit net-dns/bind-tools: add 9.18.0 reads:

Code: Select all

    net-dns/bind-tools: add 9.18.0

    This is just a proxy for net-dns/bind. Splitting the ebuilds is *way* too
    fragile and gains nothing because the same software gets built again anyway,
    just thrown away at the end.

I am not sure if the maintainer will see this discussion here. So I would suggestion open a bug request.

however I agree dmpogo's point, having the ebuild in the first place is intent for a non-server type machine to utilise included tools for discover or troubleshoot DNS relate issue. in the case non-server type machine have no reason to install DNS (bind) server related binary or support source code.

if net-dns/bind introduce new USE FLAG(s) that will create a condition where only tools got installed than this change I can accept. This almost like sys-fs/lvm2 package, that default USE flag actually skipping build lvm binary. this kind of ebuild design logic just strange. But at least it give a way to include binary in to build process and release a new item to warn about it.

[sam_]

As I read the git log output for net-dns/bind-tools, it is not a mistake. Commit net-dns/bind-tools: add 9.18.0 reads:

Code: Select all

    net-dns/bind-tools: add 9.18.0

    This is just a proxy for net-dns/bind. Splitting the ebuilds is *way* too
    fragile and gains nothing because the same software gets built again anyway,
    just thrown away at the end.

That is bizarre, yes bind-tools uses the same tarball, but what is installed at the end is quite different. You do not have any .h include files, not libraries, any init.d scripts polluting startup, no daemons (which can be launched accidentally). What are they talking about ?
Result matters more than how the compilation goes. Utilities are not daemons

There's nothing bizarre about it. One can dislike the outcome without it being bizarre. You can read the discussion on the bug for the long-winded debate about it, including the issues from trying to make it split. It ended up being fragile, building redundant components, and having to manually keep a list of files to delete in sync. You would also end up with having to apply patches twice to both packages and doing hacks to avoid collisions with them installing the same internal libraries.

[Hu]

I am only reporting what can be trivially read from git log on gentoo.git. I have no insight into the decisions or the facts that drove them.

[pingtoo]

As I read the git log output for net-dns/bind-tools, it is not a mistake. Commit net-dns/bind-tools: add 9.18.0 reads:

Code: Select all

    net-dns/bind-tools: add 9.18.0

    This is just a proxy for net-dns/bind. Splitting the ebuilds is *way* too
    fragile and gains nothing because the same software gets built again anyway,
    just thrown away at the end.

That is bizarre, yes bind-tools uses the same tarball, but what is installed at the end is quite different. You do not have any .h include files, not libraries, any init.d scripts polluting startup, no daemons (which can be launched accidentally). What are they talking about ?
Result matters more than how the compilation goes. Utilities are not daemons

There's nothing bizarre about it. One can dislike the outcome without it being bizarre. You can read the discussion on the bug for the long-winded debate about it, including the issues from trying to make it split. It ended up being fragile, building redundant components, and having to manually keep a list of files to delete in sync. You would also end up with having to apply patches twice to both packages and doing hacks to avoid collisions with them installing the same internal libraries.

I would agree the term "bizarre", because if it is due to difficult maintain, than the ebuild should just be dropped, not keep in tree. have the ebuild named bind-tools and yet it does not offer what the name imply is in my view a bizarre idea.

I can accept from maintainer point of view that it cost large effort to maintain. and because that want to reduce redundant effort. my kudos to maintainer for the dedicated work.

[sam_]

I think we've done what you described. bind-tools is now a dummy ebuild which depends on bind (does nothing else - installs no files, etc). It will be dropped eventually, leaving only bind.

[pingtoo]

I think we've done what you described. bind-tools is now a dummy ebuild which depends on bind (does nothing else - installs no files, etc). It will be dropped eventually, leaving only bind.

Thank you for clarification.

I am not yet at stage that have done anything about bind-tools package update. So I am not aware the detail. My discussion just purely base on what was discussed in this thread.

[dmpogo]

As I read the git log output for net-dns/bind-tools, it is not a mistake. Commit net-dns/bind-tools: add 9.18.0 reads:

Code: Select all

    net-dns/bind-tools: add 9.18.0

    This is just a proxy for net-dns/bind. Splitting the ebuilds is *way* too
    fragile and gains nothing because the same software gets built again anyway,
    just thrown away at the end.

That is bizarre, yes bind-tools uses the same tarball, but what is installed at the end is quite different. You do not have any .h include files, not libraries, any init.d scripts polluting startup, no daemons (which can be launched accidentally). What are they talking about ?
Result matters more than how the compilation goes. Utilities are not daemons

There's nothing bizarre about it. One can dislike the outcome without it being bizarre. You can read the discussion on the bug for the long-winded debate about it, including the issues from trying to make it split. It ended up being fragile, building redundant components, and having to manually keep a list of files to delete in sync. You would also end up with having to apply patches twice to both packages and doing hacks to avoid collisions with them installing the same internal libraries.

Bizarre is the logic offered. Any decisions can be made, but stating "gains nothing because the same software gets built again anyway,
just thrown away at the end" is bizarre, since that is not the point of having tools separate.

[sam_]

If you read the extensive discussion in the bug linked in the commit, you'll see there was more to it than that.

(I accept the commit message could've been more detailed, but we were stuck on EOL bind for quite some time, and I wanted this in finally. In general, I tend to have quite verbose commit messages, but in this instance, I failed. Commit messages are broadly more developer or power-user facing so we also don't reiterate every policy that leads to a decision either.)

[Zucca]

I think it could be possible to have server and tools USE -flags to control which parts to install at src_install().

[sam_]

You'd then be introducing REQUIRED_USE hassle (do we require at least-one-of? yes, I guess so. then what do we default it to?). It is ugly to have something where you need at least one USE flag for it to be useful.

You also then need to refine the list to ensure we delete the right binaries and don't ever accidentally delete something that the server component depends on, or vice-versa. It also then becomes a "small files policy" issue given the binaries themselves should be small given they use the same shared internal libraries. Keep in mind that the Makefile AFAIK has no specific targets for this either.

[Zucca]

Yes. USE flags make things more complicated (in this case at least).
So maybe just introducing tools-only flag (which would be off by default) for users who really need to exclude the server side stuff for whatever reasons.

[sam_]

We generally avoid *-only or minimal ("negative logic") as it has its own problems. It still then relies on manually keeping a list up to date too. This approach (manually deleting files) is generally problematic when it comes to managing dependencies too.

Sorry, but this isn't compelling. Use INSTALL_MASK.

[Zucca]

Use INSTALL_MASK.

I think that's the "correct" way if users do want to drop the server stuff.

I'm on the same line as you with the "negative flags". My last post was merely a one way to implement this using only one flag. So the preferable way to implement this via USE flag would be to introduce server flag, which would be on by default.

However if this package is fragile when it comes to stripping off parts of it (which I assume based on comments and the absence of such make target from the upstream), I'd rather choose to have the "bloat".
Those who really can't afford keeping the server side of this package can use INSTALL_MASK, but with "if it breaks, you'll get to fix it by yourself".

[pjp]

Use INSTALL_MASK.

I think that's the "correct" way if users do want to drop the server stuff.

I'm on the same line as you with the "negative flags".

*coughs n lvm2[lvm]*

In both cases it seems like upstream ought to handle it "better."

[dmpogo]

Yes. USE flags make things more complicated (in this case at least).
So maybe just introducing tools-only flag (which would be off by default) for users who really need to exclude the server side stuff for whatever reasons.

I understand that some situations can be difficult and with no easy and obvious solution, so one lives with whatever it is.

But just as comment, I would guess that less than 5% of users knowingly run "named' server. It is not needed for a vast majority. I have 5 machines to administer, none of them runs named.
2 machines at home use the routers name server (and I bet most people do the same), the ones in the workplace use name servers provided by the university. Connection is fast, there is no point to run anything locally.

But I do use dig from time to time, for one if I see suspicious activity from outside.

INSTALL_MASK may be a necessary kludge, but is far from user level expected interface. How do I know what to mask?

[szatox]

You'd then be introducing REQUIRED_USE hassle (do we require at least-one-of? yes, I guess so. then what do we default it to?). It is ugly to have something where you need at least one USE flag for it to be useful.

Oh, in this particular case it's looks quite easy: always enable tools, since they are useful for both, servers running bind, and power users on machines not running servers, as well as servers running other implementations than bind (I use powerdns and bind-tools still come in handy).
Pretty much anyone running bind server will also want related tools anyway, so there's little reason to ever disable this part, but having "named" or "bind-server" flag could be useful. Whether it should be enabled or disabled by default kinda depends on the name of ebuild remaining in the tree, so opt-out if it's bind, and opt-in if it's bind-tools (I'd personally choose the latter, but whatever)

Use INSTALL_MASK.
I think that's the "correct" way if users do want to drop the server stuff.

That's a hack though, isn't it?
Feels a bit like "You can certainly try..." said with a devious smile in response to someone suggesting a particularly creative idea that is _totally_ _not_ going to backfire under _any_ circumstances, no need to worry about it, I swear you'll be fine, lol.

Fortunately, just having bind9 server executables accidentally installed is not the end of the world as long as it doesn't automagically activate its init scripts.

[sam_]

If it bothers one that much, they can use INSTALL_MASK, with the same caveats that apply to why I don't want to maintain a manual list of files to prune in the ebuild. (My remarks on REQUIRED_USE were really an aside for the comment about two USE though.)

[Zucca]

My preferred way would be to have USE="server" for bind package. But if that could possibly cause a lot of breakages, then better to just go "all-in" and have the server stuff come along. I know some people like to drop all the unnecessary bits off to limit possible attack vectors...

I haven't dug enough deep to say which is the better option from packager's perspective, so I trust sam_ on this.

[dmpogo]

My preferred way would be to have USE="server" for bind package. But if that could possibly cause a lot of breakages, then better to just go "all-in" and have the server stuff come along. I know some people like to drop all the unnecessary bits off to limit possible attack vectors...

I haven't dug enough deep to say which is the better option from packager's perspective, so I trust sam_ on this.

From user perspective that would be most logical setup. Should be easier, just have internal INSTALL_MASK on everything server related when USE='-server' ?