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: 2924 bytes --]

On Monday, October 17, 2016 9:46:12 PM EDT Kent Fredric wrote:
> On Mon, 17 Oct 2016 03:41:13 -0400
> 
> "William L. Thomson Jr." <wlt-ml@o-sinc.com> wrote:
> > To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin. NO more.
> 
> It would be far better to simply have a PROPERTIES field in ebuilds or
> somesuch:

A -bin package is coming in as a dependency. How you do you know where it came 
from?

> PROPERTIES="binary:upstream"
> 
> or
> 
> PROPERTIES="binary:gentoo"
> 
> Assuming the right tooling, this allows a way to "canonically" define
> what the type of binary is, and allow people to make whatever choices,
> including automated rules.

That is one way to go, but one would have to spend time to find out the source.

> After you do that, you can deem a *convention* of adding -bin suffixes,
> but instead of making it a "rule", make it simply a pattern that people
> can follow if their package indicates they need suffixing.

Patterns rather than rules/policies lead to inconsistent practice which is the 
case now.

> This means:
> 
> 1. "bin" packages don't need "-bin" suffixes, because metadata will convey
> it 2. ... however, you can still use a "-bin" suffix and its encouraged.

That doesn't really make sense with 1, saying you do not need -bin suffix but 
then it is encouraged?

> 3.
> packages that end with '-bin' suffixes, but *arent* binaries can be clearly
> identified as such via metdata. ( Imagine something like
> dev-util/recycle-bin  )

The main issue I see with metadata is time. If your updating a system or 
several, a new -bin shows up potentially. You will have to spend time to 
determine the type of bin.

It also does not provide any "notification" to others that hey, this can be 
packaged from source.

> 4. any additional finessing of names to indicate what is going on can
> be decided by the maintainers in question, on a "as necessary basis"

Which leads to more inconsistency in tree. The idea is to have it consistent 
per policy and not leaving naming up to a maintainer.

> This means instead of "require this pattern" which will eventually
> result in useless chaos as packages rename all over the place, it will
> also avoid "require this pattern" where its not needed. ( neither
> www-client/opera, www-client/opera-developer, or www-client/opera-beta
> are source based, they're all binaries, unpacked from .deb's for crying
> out loud )

Then they should all have the -bin suffix. Already showing deviation from that 
while other packages have it. Exactly the inconsistency a policy would 
address.

> And we don't want to embrace visibly the idea that "free for all
> binaries!!!!" by having too many -bin packages in tree.

Part of the idea is to prevent the growing -bins in tree....

Do you have any ideas how to reduce that and get others to help package things 
that other stick in tree as binary rather than from source?

-- 
William L. Thomson Jr.

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