On Saturday, October 15, 2016 4:10:51 PM EDT Kent Fredric wrote:
>
> Yeah, I get the intent, but I don't see it being likely we'd ever have
> a real usecase for having both a -bin and a -gbin in tree together.

You actually came up with one I was not considering at first but provides a 
direct technical benefit you cannot achieve with a USE flag.
 
> If anything, I'd imagine if that case arose, it would manifest itself more
> as:
> 
>    icedtea-bin + USE=official

Then how would you test that against non official? You cannot install the same 
package twice at the same time with different USE flags. You can't even make 
binaries easily of the same package with different USE flags. The previous 
binary will get overwritten.

> Or similar, given the "deploy binary to system" steps are likely to be
> the same regardless of who built it.

That is an assumption, they might have different dependencies, require 
different changes upon install as a result. Or other things that would have a 
different install phase, but likely most would be the same.

> At best, I'd imagine users who care whether they get "official" binaries
> or "gentoo" binaries would probably prefer to select which as a sort of
> global policy, but that concept is just a doorway to additional complexity.

That could be handled by virtuals.
 
> So a strong argument would have to be made for being able to "select"
> between "Offical" and "Unofficial" binaries in an automated fashion
> before we go down that road to hell.

There you go, a case why it would make sense to have it be -bin and -ebin. 
You can install both those at the same time and test.

Maybe the upstream binary runs better, does not crash, etc. Or the Gentoo one 
does. If the Gentoo one is better, it could be used to get a reluctant 
upstream to make changes. If worse could be used to help figure out where its 
going wrong.

I would go even further and do something like -sbin, to represent this is a 
binary of an ebuild that could be built from source. Since there are binaries 
in tree that are closed source cannot. There are also large complex open 
source packages that are in tree as binary due to a lack of man power....

Part of the idea is to help differentiate the types of binaries in tree to 
hopefully get less binaries that are from source.

To start I just wanted to see about a policy for -bin, the other stuff was 
just extra after -bin itself was a policy. Unless it made sense to develop it 
in full,

-bin - Closed source binary ebuild
-ebin - Self made binary from source
-sbin - Binary ebuild of an open source package

-- 
William L. Thomson Jr.