Re: [gentoo-dev] Package file name requirement for binary ebuilds

[Ian Stakenvicius <axs@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4880 bytes --]

On 16/10/16 10:43 PM, William L. Thomson Jr. wrote:
> On Sunday, October 16, 2016 9:19:25 PM EDT Ian Stakenvicius wrote:
>>
>> *IF* we were going to make use of upstream vs gentoo-generated binary
>> packages in the tree, they *WOULD* block one-another as they would
>> collide file-wise at least partially if not completely.  So there
>> wouldn't be any testing between the two variants on the same installed
>> system.
> 
> That was not an argument I was initially making as justification, but via 
> slotting and changing names of binaries and/or paths it could be done.
> 
> It is in part why systems like eselect exist to switch between 
> implementations. In Java's case there is a wrapper around all binaries that is 
> called, which handles which ones is used. run-java-tool.bash. In addition to 
> things like java-cpnfig etc.
> 
> Also why there is gcc-config, binutils-config, etc. Part of the beauty of Gentoo 
> is installing things that collide, and switching between them for testing.
> 
>>> 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.
>>
>> OK, so here's how things *actually work* in the gentoo repo:
> 
> Because I need such an explanation? I think it could be a little less harsh 
> no?
> 
>> #1, binary packages aren't made unless there's a really good reason
>> for them -- the primary one being that there isn't any other option
>> provided by upstream.
> 
> Is that a mandated policy? There are ebuilds in tree that are not that way.
> 
>> #2, if there is a binary package then the only reason why a gentoo dev
>> would roll it instead of using upstream's version is because the
>> upstream one fails hard or has too many bugs, security
>> vulnerabilities, whatever.  This is as much done on a per-version
>> basis within a package as it is on a per-package one.
> 
> There is a 3rd case, where the package is to complex to package from source. 
> Things like jenkins-bin, and there are others... jenkins can be packaged from 
> source, as some others can be. If they were -sbin, maybe more would be aware 
> and try to package from source vs use as binary because it is to hard to 
> package from source.
> 
>> All of this discussion is centered around trying to bring convention
>> to a problem that simply doesn't exist.  
> 
> Maybe you are just not aware. Which if the packages were required to be named, 
> say -sbin a binary that is a from source package, just not packaged you would 
> be aware.
> 
> They exist, go look! Also seems to be growing.
> 
>> Also, if the idea here is to
>> open the door for a flood of gentoo-dev-rolled *-bin packages in the
>> gentoo repo for end-user convenience,
> 
> No that is not the case, and that is done in extreme limited case. I am not 
> pushing for more binary packages by any means. It would simply be to 
> differentiate, so anyone knows by file name what they are getting, from 
> upstream or from Gentoo.
> 
>> then we should similarly stop
>> this discussion right now too.  How about, instead, you could focus on
>> setting up two (additional) repos -- one containing gentoo-built
>> binary packages, another containing upstream-only packages.
> 
> That is not my goal. I am trying to bring to attention -bin packages in tree. 
> -sbin packages should draw attention to get people to package them from 
> source.
> 
>> That way
>> it'll be very obvious to end-users what they'll be using because
>> they'll know exactly based on where it comes from. 
> 
> This is an issue of things already in tree, and packages being added in tree, 
> in Gentoo's repo. Which I obviously cannot do so its not my work.
> 
>> It'll also be very
>> easy for end-users to control which one is used, just by choosing
>> which repo it comes from.  AND, it'll keep them from polluting the
>> main gentoo repo too.
> 
> It is already polluted, seems you are unaware, but now you know.
> 
> Likely wasn't intentional but came across VERY hostile, and completely missing 
> the mark and point.
> 

It wasn't meant to be hostile but yes my patience was lacking and I
apologize.

I agree, there are a number of binary packages in the tree already and
fortunately most of them have a -bin in their name despite this not
being any formal requirement.  There is also no particular policy that
I am aware of for ensuring packages are designed to be built from
source first and foremost -- however it doesn't make much sense to
have a source-based distro full of precompiled binaries and so I do
believe pretty well every developer strives to make this so whenever
possible, given that's sort of our purpose here.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]