| 1 |
On 16/10/16 06:30 PM, William L. Thomson Jr. wrote: |
| 2 |
> On Saturday, October 15, 2016 4:10:51 PM EDT Kent Fredric wrote: |
| 3 |
>> |
| 4 |
>> Yeah, I get the intent, but I don't see it being likely we'd ever have |
| 5 |
>> a real usecase for having both a -bin and a -gbin in tree together. |
| 6 |
> |
| 7 |
> You actually came up with one I was not considering at first but provides a |
| 8 |
> direct technical benefit you cannot achieve with a USE flag. |
| 9 |
> |
| 10 |
>> If anything, I'd imagine if that case arose, it would manifest itself more |
| 11 |
>> as: |
| 12 |
>> |
| 13 |
>> icedtea-bin + USE=official |
| 14 |
> |
| 15 |
> Then how would you test that against non official? You cannot install the same |
| 16 |
> package twice at the same time with different USE flags. You can't even make |
| 17 |
> binaries easily of the same package with different USE flags. The previous |
| 18 |
> binary will get overwritten. |
| 19 |
|
| 20 |
|
| 21 |
*IF* we were going to make use of upstream vs gentoo-generated binary |
| 22 |
packages in the tree, they *WOULD* block one-another as they would |
| 23 |
collide file-wise at least partially if not completely. So there |
| 24 |
wouldn't be any testing between the two variants on the same installed |
| 25 |
system. |
| 26 |
|
| 27 |
|
| 28 |
|
| 29 |
> Maybe the upstream binary runs better, does not crash, etc. Or the Gentoo one |
| 30 |
> does. If the Gentoo one is better, it could be used to get a reluctant |
| 31 |
> upstream to make changes. If worse could be used to help figure out where its |
| 32 |
> going wrong. |
| 33 |
|
| 34 |
OK, so here's how things *actually work* in the gentoo repo: |
| 35 |
|
| 36 |
#1, binary packages aren't made unless there's a really good reason |
| 37 |
for them -- the primary one being that there isn't any other option |
| 38 |
provided by upstream. |
| 39 |
|
| 40 |
#2, if there is a binary package then the only reason why a gentoo dev |
| 41 |
would roll it instead of using upstream's version is because the |
| 42 |
upstream one fails hard or has too many bugs, security |
| 43 |
vulnerabilities, whatever. This is as much done on a per-version |
| 44 |
basis within a package as it is on a per-package one. |
| 45 |
|
| 46 |
All of this discussion is centered around trying to bring convention |
| 47 |
to a problem that simply doesn't exist. Also, if the idea here is to |
| 48 |
open the door for a flood of gentoo-dev-rolled *-bin packages in the |
| 49 |
gentoo repo for end-user convenience, then we should similarly stop |
| 50 |
this discussion right now too. How about, instead, you could focus on |
| 51 |
setting up two (additional) repos -- one containing gentoo-built |
| 52 |
binary packages, another containing upstream-only packages. That way |
| 53 |
it'll be very obvious to end-users what they'll be using because |
| 54 |
they'll know exactly based on where it comes from. It'll also be very |
| 55 |
easy for end-users to control which one is used, just by choosing |
| 56 |
which repo it comes from. AND, it'll keep them from polluting the |
| 57 |
main gentoo repo too. |
Archives