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.
signature.asc
Description: This is a digitally signed message part.
