openssl and bindist conflicts [SOLVED]

hunky · l33t Joined: 19 Nov 2003 Posts: 910 Location: Alaska

Possibly related to this bug: https://bugs.gentoo.org/show_bug.cgi?id=531540, I've got a conflict when trying to emerge update world.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

If you want dev-qt/qtnetwork with SSL support, you need USE="-bindist" on openssl.
If you want net-misc/openssh, you need the same ±bindist on both packages.

This error is happening because you have USE="bindist" set somewhere. Why you'd want to reduce functionality by setting it is only something you can answer.

hunky · l33t Joined: 19 Nov 2003 Posts: 910 Location: Alaska

See, there ya go, Ant P. Something obvious I had overlooked. Had it in my USE flags - make.conf.

So appreciate the response - fixed it.

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

You misunderstood the output from Portage. Yes, bind requires that openssl have USE=-bindist. However, qtnetwork does not require bindist to be enabled. It requires bindist to match. That is, dev-qt/qtnetwork[-bindist] dev-libs/openssl[-bindist] is legal and dev-qt/qtnetwork[bindist] dev-libs/openssl[bindist] is legal, but dev-qt/qtnetwork[bindist] dev-libs/openssl[-bindist] is disallowed and dev-qt/qtnetwork[-bindist] dev-libs/openssl[bindist] is disallowed. You have bindist enabled on one package and disabled on the other, which is a disallowed state, so you get an error. Since bind wants USE=-bindist, you need dev-libs/openssl[-bindist] for that. Therefore, the only solution to use both bind and qtnetwork is to set USE=-bindist on both openssl and qtnetwork.

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

ct85711 · Veteran Joined: 27 Sep 2005 Posts: 1791

I just wanted to mention, that bindist means you want to distribute binary copies of the packages and to disable proprietary code in that package , NOT use a binary copy. If you want a binary copy, it will have the "-bin" in the package name; assuming the devs bothered to have a binary version of the package.

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

That is a fairly common configuration among people who have the hardware and the environment to support it. You might hit some packages that behave poorly with distcc, but I cannot recall anyone who claims to have broken their system by doing it that way. Your biggest risk is that you someday want one of the machines to have different USE flags than its peers, and then it has to be configured specially to support that.

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

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

Aarrgg.

Rebuilding due to profile 13 being dropped from support. Now building profile 17 system from scratch.

So, back to the issue of to bindist or not to bindist.

bind won't accept bindist, and mirrorselect insists on bindist.
So the two mutually exclusive, right? Either you can have bind, or you can have mirroselect, but not both.
'Cause you can only have either +bindist, or -bindist, but not both?

I must have some sort of brain damage, or missing piece of information or realization that's preventing me from sorting this out myself.

I'm finding myself going around in circles, and while portage keeps dutifully making suggestions, applying them only seems to make everything worse and cough up yet more use flags, mask flags, and unmassk flags that it demands be set.

What's the most generic USE variable value that would virtually allow everything to be complied all the time?
Larger executables is not an issue, disk space isn't an issue, and memory consumption isn't an issue, even longer build times isn't an issue, all these things are relatively cheap.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

The simplest choice would be not to define USE at all. It sounds wrong to me that mirrorselect would require bindist. Please post the output of emerge --pretend --verbose app-portage/mirrorselect net-dns/bind dev-libs/openssl.

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

Yea, setting the USE="" in the make.conf, seems to really help matters.

Got everything silenced when running

emerge -p --newuse world

When I add mirrorselect (emerge -p --newuse world mirrorselect) it first demands:

=dev-libs/openssl-1.0.2n -bindist

OK, so add that. Run it again, then it demands:

=dev-libs/openssl-1.0.2n bindist

Maybe I'll just skip mirror select?

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

OK, so I've given up on mirrorselect, change the make.conf USE to:

USE="aqua wayland X egl server"

Then emerge -p --newuse world comes back without a complaint.

Guess I'll go with that for now.

I wonder if there's something like USE="*" for a 'everything including the kitchen sink'?

asturm · Developer Joined: 05 Apr 2007 Posts: 8936

Why 'aqua'?

Furthermore, yes it seems you have dropped 'bindist' from make.conf, but you haven't rebuilt affected packages (-N world) such as openssh. Your system is not fixed until that is done.

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

Always manage bindist globally. Never make exceptions for specific packages. Generally, packages that have IUSE=bindist will require that any supporting packages that IUSE=bindist have a matching value. You can find specific cases where you can flip it from your global default, but your life will be simpler if you manage bindist globally and make no exceptions. Most USE flags are not like that.

As for whether to enable it, I suggest you read what it does, evaluate whether the restrictions it imposes are relevant to your use case, then set your USE accordingly. For most people, USE=-bindist is fine. For those who need it, it's present.

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

Answering my own question.

Better to not have bindist in the global USE flags in make.conf, and only enable it for specific packages in their individual .use files.

When making a change like this, you have to be sure to unmerge the installed packages that have it already enabled before trying to install anything that doesn't have it enabled, as this is where a conflict is going to come from.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

Why would you want to enable it at all? As it says, bindist is only for people who redistribute binary packages to others.

eohrnberger · Apprentice Joined: 09 Dec 2004 Posts: 240

asturm · Developer Joined: 05 Apr 2007 Posts: 8936

Yes... if you want the branding you usually need to keep it disabled...

yanlinlin82 · n00b Joined: 27 Aug 2013 Posts: 2 Location: Beijing, China

I have been struggling with such conflict recently. Since there are so many ebuild configure dependencies as "openssl [-bindist]" rather than "openssl [=bindist]", I guess it is better setting USE="bindist" for individuals package instead of setting it globally.