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