| 1 |
On Sun, 16 Oct 2016 18:20:42 -0400 |
| 2 |
"William L. Thomson Jr." <wlt-ml@××××××.com> wrote: |
| 3 |
|
| 4 |
> Part of the idea everyone is missing is time... It takes time to go look at |
| 5 |
> information a package metadata.xml If the package is coming in as a |
| 6 |
> dependency. Instead of just being able to visually look at the package name |
| 7 |
> and know. |
| 8 |
> |
| 9 |
> This is a binary package from upstream |
| 10 |
> This is a binary package from Gentoo |
| 11 |
|
| 12 |
There's quite a lot of metadata that *might* be important ( but isn't ) and is only |
| 13 |
available as metadata, not visible in the package name itself. |
| 14 |
|
| 15 |
Like, LICENSE, and "where its fetched from" |
| 16 |
|
| 17 |
dev-lang/perl-artistic-gpl2+-cpan-5.24.1 |
| 18 |
|
| 19 |
This is just getting silly. |
| 20 |
|
| 21 |
Exposing metadata in the package atom should be out of *necessity*, |
| 22 |
not some misguided sense of visibility. |
| 23 |
|
| 24 |
For every other kind of metadata, those who care about it should invest |
| 25 |
effort into exposing it. |
| 26 |
|
| 27 |
That's why my example elsewhere abuses the LICENSE field to demonstrate |
| 28 |
how end users can make a choice/see the reality using out-of-name |
| 29 |
metadata. |
| 30 |
|
| 31 |
But there is quite frankly no *need* for -gbin and -bin |
| 32 |
|
| 33 |
The only real /technical/ reason we have both -bin and -gbin is it |
| 34 |
avoids the binary version competing for a name with the source-built |
| 35 |
version. |
| 36 |
|
| 37 |
That is, if there is a "-bin" package, its viable some day there may be |
| 38 |
a non "-bin" package, and that they may both be available side-by-side |
| 39 |
and you may wish to choose between them. |
| 40 |
|
| 41 |
But "-gbin" and "-bin" coexisting side-by side is a usecase I can't see |
| 42 |
being useful to anybody. |
Archives