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

[William L. Thomson Jr.]

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.

-- 
William L. Thomson Jr.