1 |
On Monday, October 17, 2016 03:37:28 AM William L. Thomson Jr. wrote: |
2 |
> On Monday, October 17, 2016 8:57:30 AM EDT Michał Górny wrote: |
3 |
> > On Sun, 16 Oct 2016 18:30:44 -0400 |
4 |
> > |
5 |
> > "William L. Thomson Jr." <wlt-ml@××××××.com> wrote: |
6 |
> > > Part of the idea is to help differentiate the types of binaries in tree |
7 |
> > > to |
8 |
> > > hopefully get less binaries that are from source. |
9 |
> > > |
10 |
> > > To start I just wanted to see about a policy for -bin, the other stuff |
11 |
> > > was |
12 |
> > > just extra after -bin itself was a policy. Unless it made sense to |
13 |
> > > develop |
14 |
> > > it in full, |
15 |
> > > |
16 |
> > > -bin - Closed source binary ebuild |
17 |
> > > -ebin - Self made binary from source |
18 |
> > > -sbin - Binary ebuild of an open source package |
19 |
> > |
20 |
> > Let's also add -c for C programs, and -cxx for C++ programs. -py for |
21 |
> > pure Python stuff, -cpy when stuff includes extensions compiled in C, |
22 |
> > -cxxpy extensions in C++. We should also have special -x86asm suffix |
23 |
> > for packages that rely on non-portable x86 assembly, or maybe even |
24 |
> > -x86asm-sse when they use some fancy instruction sets. And then don't |
25 |
> > forget to add a suffix for license, for GUI library (because obviously |
26 |
> > nobody wants GTK+ software on KDE systems, nor GTK+3 software on GTK+ |
27 |
> > systems). |
28 |
> |
29 |
> Clearly being sarcastic as a binary is a binary. It doesn't matter what |
30 |
> language, toolkit etc. |
31 |
|
32 |
And what about when a package is mixed? When it has a closed firmware blob, or |
33 |
a statically-linked helper utility? Often, you'll see that stuff get unbundled, |
34 |
but does that even make sense when the blob or helper utility is only used by |
35 |
that package? |
36 |
|
37 |
-- |
38 |
:wq |