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