| 1 |
On 14/10/16 01:17 PM, William L. Thomson Jr. wrote: |
| 2 |
> On Friday, October 14, 2016 1:09:25 PM EDT Ian Stakenvicius wrote: |
| 3 |
>> On 14/10/16 01:05 PM, William L. Thomson Jr. wrote: |
| 4 |
>>> Problem |
| 5 |
>>> 2. There are binary packages that end in -bin, which is good. However it |
| 6 |
>>> is |
| 7 |
>>> not clear if that is an upstream 3rd party binary. Or a binary made by |
| 8 |
>>> compiling a large Gentoo package, by a Gentoo dev or contributor on a |
| 9 |
>>> Gentoo system. Like icedtea-bin for example, and likely some others. |
| 10 |
>> |
| 11 |
>> Is there a reason that this differentiation would matter? |
| 12 |
> |
| 13 |
> In my opinion yes, the following reasons at minimum |
| 14 |
> |
| 15 |
> 1. Upstream binary little can be done if there are issues. Maybe changing |
| 16 |
> things on the system, but cannot change what it was built/linked against etc. |
| 17 |
> Bugs there would be filed against upstream, not really Gentoo as there is |
| 18 |
> nothing that can be done to change the binary itself. |
| 19 |
> |
| 20 |
> 2. Gentoo made binaries can be remade if there are issues. Bugs on those |
| 21 |
> should be filed against Gentoo rather than upstream. There is also a process to |
| 22 |
> making those binaries. It may be as simple as emerging a Gentoo package and |
| 23 |
> creating a tarball, or it may not. Others may need to know how to do such if |
| 24 |
> someone moves on. Most times that is not documented, and people have no idea |
| 25 |
> if the binary was made for Gentoo on Gentoo, or just re-packaged upstream. |
| 26 |
> |
| 27 |
> 3. The obvious reason to have a -bin in general, is to let anyone know they |
| 28 |
> are merging a binary package. Which may or may not be wanted. Also shows what |
| 29 |
> packages may need to be packaged from source if possible. People may choose to |
| 30 |
> emerge a self made Gentoo binary more often than say a third party one. Since |
| 31 |
> they know it was built on a Gentoo system, just saves them from having to |
| 32 |
> compile themselves. They also may trust a Gentoo made binary more than one |
| 33 |
> from upstream, but that is speculative. |
| 34 |
> |
| 35 |
> Mostly reasons 1 and 2, 3 is a side benefit but not the major rational. |
| 36 |
> |
| 37 |
|
| 38 |
So, #1, if there's a problem we should still have bugs in gentoo's |
| 39 |
bugzilla -- there may be little that can be done to the package but if |
| 40 |
the issue is with integration into the rest of gentoo that is |
| 41 |
absolutely within the realm of the maintainer to address. Either way, |
| 42 |
having the package's name indicate if its an upstream binary or not is |
| 43 |
rather moot to this one. |
| 44 |
|
| 45 |
#2, see #1 regarding bugs; regarding maintenance, this isn't a whole |
| 46 |
lot different from training replacement devs in how to handle a |
| 47 |
foreign build system or managing very complex configuration options -- |
| 48 |
that is, instructions or documentation or helper scripts should be |
| 49 |
made available and shared somewhere not in the package. Having the |
| 50 |
package name indicate upstream-bin vs gentoo-bin doesn't help this one |
| 51 |
either. |
| 52 |
|
| 53 |
#3, this may have merit in terms of using an alternate package name |
| 54 |
for upstream vs gentoo rolled binaries, but realistically i'm not |
| 55 |
seeing a need for the separation in the package's NAME unless we're |
| 56 |
going to have both gento-rolled and upstream-rolled binaries in the |
| 57 |
repo at the same time, competing with eachother. It would be just as |
| 58 |
effective IMO to list if the package is gentoo-rolled or not in its |
| 59 |
description in metadata, no need to (re)define the package name. |
Archives