On Mon, 17 Oct 2016 03:41:13 -0400
"William L. Thomson Jr." <wlt...@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:

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.

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.

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.
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  )
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"

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 )

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

We have to keep it balanced.

Attachment: pgpEWWJIdl2ZB.pgp
Description: OpenPGP digital signature

Reply via email to