Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
bind-tools bloat
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
darkphader
Veteran
Veteran


Joined: 09 May 2002
Posts: 1221
Location: Motown

PostPosted: Mon Sep 02, 2024 7:57 pm    Post subject: bind-tools bloat Reply with quote

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.
_________________
WYSIWYG - What You See Is What You Grep
Back to top
View user's profile Send private message
freke
Veteran
Veteran


Joined: 23 Jan 2003
Posts: 1020
Location: Somewhere in Denmark

PostPosted: Mon Sep 02, 2024 8:14 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3376
Location: Canada

PostPosted: Mon Sep 02, 2024 8:19 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22404

PostPosted: Mon Sep 02, 2024 9:11 pm    Post subject: Reply with quote

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:
    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.
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3376
Location: Canada

PostPosted: Mon Sep 02, 2024 9:31 pm    Post subject: Reply with quote

Hu wrote:
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:
    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
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6144
Location: Dallas area

PostPosted: Mon Sep 02, 2024 9:41 pm    Post subject: Reply with quote

For the dig utility, I would use the old version, it's not like it needs to be constantly updated.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
pingtoo
Veteran
Veteran


Joined: 10 Sep 2021
Posts: 1125
Location: Richmond Hill, Canada

PostPosted: Mon Sep 02, 2024 9:55 pm    Post subject: Reply with quote

Hu wrote:
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:
    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.
Back to top
View user's profile Send private message
sam_
Developer
Developer


Joined: 14 Aug 2020
Posts: 1867

PostPosted: Mon Sep 02, 2024 9:56 pm    Post subject: Reply with quote

dmpogo wrote:
Hu wrote:
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:
    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.
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22404

PostPosted: Mon Sep 02, 2024 9:58 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
pingtoo
Veteran
Veteran


Joined: 10 Sep 2021
Posts: 1125
Location: Richmond Hill, Canada

PostPosted: Mon Sep 02, 2024 10:06 pm    Post subject: Reply with quote

sam_ wrote:
dmpogo wrote:
Hu wrote:
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:
    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.


Last edited by pingtoo on Mon Sep 02, 2024 10:08 pm; edited 1 time in total
Back to top
View user's profile Send private message
sam_
Developer
Developer


Joined: 14 Aug 2020
Posts: 1867

PostPosted: Mon Sep 02, 2024 10:07 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
pingtoo
Veteran
Veteran


Joined: 10 Sep 2021
Posts: 1125
Location: Richmond Hill, Canada

PostPosted: Mon Sep 02, 2024 10:12 pm    Post subject: Reply with quote

sam_ wrote:
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.
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3376
Location: Canada

PostPosted: Mon Sep 02, 2024 10:24 pm    Post subject: Reply with quote

sam_ wrote:
dmpogo wrote:
Hu wrote:
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:
    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.
Back to top
View user's profile Send private message
sam_
Developer
Developer


Joined: 14 Aug 2020
Posts: 1867

PostPosted: Mon Sep 02, 2024 10:25 pm    Post subject: Reply with quote

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.)
Back to top
View user's profile Send private message
Zucca
Moderator
Moderator


Joined: 14 Jun 2007
Posts: 3618
Location: Rasi, Finland

PostPosted: Tue Sep 03, 2024 7:34 am    Post subject: Reply with quote

I think it could be possible to have server and tools USE -flags to control which parts to install at src_install().
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
Quote:
I am NaN! I am a man!
Back to top
View user's profile Send private message
sam_
Developer
Developer


Joined: 14 Aug 2020
Posts: 1867

PostPosted: Tue Sep 03, 2024 7:41 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Zucca
Moderator
Moderator


Joined: 14 Jun 2007
Posts: 3618
Location: Rasi, Finland

PostPosted: Tue Sep 03, 2024 7:54 am    Post subject: Reply with quote

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.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
Quote:
I am NaN! I am a man!
Back to top
View user's profile Send private message
sam_
Developer
Developer


Joined: 14 Aug 2020
Posts: 1867

PostPosted: Tue Sep 03, 2024 7:59 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Zucca
Moderator
Moderator


Joined: 14 Jun 2007
Posts: 3618
Location: Rasi, Finland

PostPosted: Tue Sep 03, 2024 8:21 am    Post subject: Reply with quote

sam_ wrote:
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".
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
Quote:
I am NaN! I am a man!
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20348

PostPosted: Tue Sep 03, 2024 1:09 pm    Post subject: Reply with quote

Zucca wrote:
sam_ wrote:
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."
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3376
Location: Canada

PostPosted: Tue Sep 03, 2024 4:52 pm    Post subject: Reply with quote

Zucca wrote:
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?
Back to top
View user's profile Send private message
szatox
Advocate
Advocate


Joined: 27 Aug 2013
Posts: 3335

PostPosted: Tue Sep 03, 2024 6:02 pm    Post subject: Reply with quote

sam_ wrote:
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)

Quote:
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.
_________________
Make Computing Fun Again
Back to top
View user's profile Send private message
sam_
Developer
Developer


Joined: 14 Aug 2020
Posts: 1867

PostPosted: Wed Sep 04, 2024 12:47 am    Post subject: Reply with quote

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.)
Back to top
View user's profile Send private message
Zucca
Moderator
Moderator


Joined: 14 Jun 2007
Posts: 3618
Location: Rasi, Finland

PostPosted: Wed Sep 04, 2024 9:15 am    Post subject: Reply with quote

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.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
Quote:
I am NaN! I am a man!
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3376
Location: Canada

PostPosted: Thu Sep 05, 2024 7:14 pm    Post subject: Reply with quote

Zucca wrote:
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' ?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum