On Monday, October 17, 2016 9:40:57 AM EDT Michał Górny wrote: > 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.
It is already in practice now with regard to -bin suffix. It is just not consistent or policy. -- William L. Thomson Jr.
Description: This is a digitally signed message part.