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

[Ian Stakenvicius]

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.