On Mon, 17 Oct 2016 03:37:28 -0400
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:

> On Monday, October 17, 2016 8:57:30 AM EDT Michał Górny wrote:
> > On Sun, 16 Oct 2016 18:30:44 -0400
> > 
> > "William L. Thomson Jr." <wlt...@o-sinc.com> wrote:  
> > > Part of the idea is to help differentiate the types of binaries in tree to
> > > hopefully get less binaries that are from source.
> > > 
> > > To start I just wanted to see about a policy for -bin, the other stuff was
> > > just extra after -bin itself was a policy. Unless it made sense to develop
> > > it in full,
> > > 
> > > -bin - Closed source binary ebuild
> > > -ebin - Self made binary from source
> > > -sbin - Binary ebuild of an open source package  
> > 
> > Let's also add -c for C programs, and -cxx for C++ programs. -py for
> > pure Python stuff, -cpy when stuff includes extensions compiled in C,
> > -cxxpy extensions in C++. We should also have special -x86asm suffix
> > for packages that rely on non-portable x86 assembly, or maybe even
> > -x86asm-sse when they use some fancy instruction sets. And then don't
> > forget to add a suffix for license, for GUI library (because obviously
> > nobody wants GTK+ software on KDE systems, nor GTK+3 software on GTK+
> > systems).  
> 
> Clearly being sarcastic as a binary is a binary. It doesn't matter what 
> language, toolkit etc.

It doesn't matter for you. It may matter for others. Much like having
binary signaled in name may not matter to others. Which is why in-band
signaling is a bad idea.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

Attachment: pgpubOWUxC3CF.pgp
Description: OpenPGP digital signature

Reply via email to