1 |
On Saturday, October 15, 2016 4:10:51 PM EDT Kent Fredric wrote: |
2 |
> |
3 |
> Yeah, I get the intent, but I don't see it being likely we'd ever have |
4 |
> a real usecase for having both a -bin and a -gbin in tree together. |
5 |
|
6 |
You actually came up with one I was not considering at first but provides a |
7 |
direct technical benefit you cannot achieve with a USE flag. |
8 |
|
9 |
> If anything, I'd imagine if that case arose, it would manifest itself more |
10 |
> as: |
11 |
> |
12 |
> icedtea-bin + USE=official |
13 |
|
14 |
Then how would you test that against non official? You cannot install the same |
15 |
package twice at the same time with different USE flags. You can't even make |
16 |
binaries easily of the same package with different USE flags. The previous |
17 |
binary will get overwritten. |
18 |
|
19 |
> Or similar, given the "deploy binary to system" steps are likely to be |
20 |
> the same regardless of who built it. |
21 |
|
22 |
That is an assumption, they might have different dependencies, require |
23 |
different changes upon install as a result. Or other things that would have a |
24 |
different install phase, but likely most would be the same. |
25 |
|
26 |
> At best, I'd imagine users who care whether they get "official" binaries |
27 |
> or "gentoo" binaries would probably prefer to select which as a sort of |
28 |
> global policy, but that concept is just a doorway to additional complexity. |
29 |
|
30 |
That could be handled by virtuals. |
31 |
|
32 |
> So a strong argument would have to be made for being able to "select" |
33 |
> between "Offical" and "Unofficial" binaries in an automated fashion |
34 |
> before we go down that road to hell. |
35 |
|
36 |
There you go, a case why it would make sense to have it be -bin and -ebin. |
37 |
You can install both those at the same time and test. |
38 |
|
39 |
Maybe the upstream binary runs better, does not crash, etc. Or the Gentoo one |
40 |
does. If the Gentoo one is better, it could be used to get a reluctant |
41 |
upstream to make changes. If worse could be used to help figure out where its |
42 |
going wrong. |
43 |
|
44 |
I would go even further and do something like -sbin, to represent this is a |
45 |
binary of an ebuild that could be built from source. Since there are binaries |
46 |
in tree that are closed source cannot. There are also large complex open |
47 |
source packages that are in tree as binary due to a lack of man power.... |
48 |
|
49 |
Part of the idea is to help differentiate the types of binaries in tree to |
50 |
hopefully get less binaries that are from source. |
51 |
|
52 |
To start I just wanted to see about a policy for -bin, the other stuff was |
53 |
just extra after -bin itself was a policy. Unless it made sense to develop it |
54 |
in full, |
55 |
|
56 |
-bin - Closed source binary ebuild |
57 |
-ebin - Self made binary from source |
58 |
-sbin - Binary ebuild of an open source package |
59 |
|
60 |
-- |
61 |
William L. Thomson Jr. |