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.
signature.asc
Description: OpenPGP digital signature
