bind-tools bloat

darkphader · Veteran Joined: 09 May 2002 Posts: 1225 Location: Motown

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

freke · Posted: Mon Sep 02, 2024 8:14 pm Post subject:

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 · Advocate Joined: 02 Sep 2004 Posts: 3425 Location: Canada

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 · Administrator Joined: 06 Mar 2007 Posts: 22649

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:

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3425 Location: Canada

Anon-E-moose · Posted: Mon Sep 02, 2024 9:41 pm Post subject:

For the dig utility, I would use the old version, it's not like it needs to be constantly updated.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

pingtoo · Posted: Mon Sep 02, 2024 9:55 pm Post subject:

sam_ · Developer Joined: 14 Aug 2020 Posts: 1961

Hu · Administrator Joined: 06 Mar 2007 Posts: 22649

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 · Posted: Mon Sep 02, 2024 10:06 pm Post subject:

sam_ · Developer Joined: 14 Aug 2020 Posts: 1961

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 · Posted: Mon Sep 02, 2024 10:12 pm Post subject:

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3425 Location: Canada

sam_ · Developer Joined: 14 Aug 2020 Posts: 1961

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 · Posted: Tue Sep 03, 2024 7:34 am Post subject:

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

sam_ · Developer Joined: 14 Aug 2020 Posts: 1961

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 · Posted: Tue Sep 03, 2024 7:54 am Post subject:

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 :..

sam_ · Developer Joined: 14 Aug 2020 Posts: 1961

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 · Posted: Tue Sep 03, 2024 8:21 am Post subject:

pjp · Administrator Joined: 16 Apr 2002 Posts: 20485

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3425 Location: Canada

szatox · Advocate Joined: 27 Aug 2013 Posts: 3430

sam_ · Developer Joined: 14 Aug 2020 Posts: 1961

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 · Posted: Wed Sep 04, 2024 9:15 am Post subject:

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 :..

dmpogo · Advocate Joined: 02 Sep 2004 Posts: 3425 Location: Canada