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

["William L. Thomson Jr." <wlt-ml@o-sinc.com>]

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

On Monday, October 17, 2016 3:52:52 PM EDT Kristian Fiskerstrand wrote:
>
> Off the top of my head I'm only aware of libreoffice-bin myself (and
> then it is a clear alternative to libreoffice if wanting the source),
> providing this as a binary is a convenience to end-users not wanting to
> spend 50 minutes on the compile.

That seems to be the main use of -bin, and the reason for like icedtea-bin, 
and other firefox-bin, etc. I would not suggest get rid of those, though could 
be in a different place if it bothers others.

I have always used oo-bin, but did compile libreoffice. Never compiled oo it was 
way to big.  At a point have used firefox-bin, and icedtea-bin, when not 
wanting to merge those from source. Just being lazy and not wanting some of 
the dependencies.
 
> I'm wondering if it wouldn't make sense to provide this as a binary
> package in a binhost instead of a -bin though (thats what I use
> internally myself in any case).

I am not pushing for such, but BSD does have a binary ports tree I believe 
available separate from the from source. I make my own binaries for other 
systems, to speed up updates. But I do not really use a binhost.

Long ago there was some company that was doing a repo of precompiled Gentoo 
binaries. But it went away a very long time ago. I haven't seen anything 
attempt it since. Not sure the demand, but things like Arch do exist now.

As for packages in tree as bin that can be from source, I have already pointed 
one out, dev-util/jenkins-bin. There are others.

Even if we have a list, what next? There are reasons why they are not packaged 
from source, and that will not change. Good to be aware, but without any sort 
of plan or means to address. Not sure it will matter.

-- 
William L. Thomson Jr.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 163 bytes --]