On Sun, 16 Oct 2016 18:20:42 -0400 "William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
> Part of the idea everyone is missing is time... It takes time to go look at > information a package metadata.xml If the package is coming in as a > dependency. Instead of just being able to visually look at the package name > and know. > > This is a binary package from upstream > This is a binary package from Gentoo There's quite a lot of metadata that *might* be important ( but isn't ) and is only available as metadata, not visible in the package name itself. Like, LICENSE, and "where its fetched from" dev-lang/perl-artistic-gpl2+-cpan-5.24.1 This is just getting silly. Exposing metadata in the package atom should be out of *necessity*, not some misguided sense of visibility. For every other kind of metadata, those who care about it should invest effort into exposing it. That's why my example elsewhere abuses the LICENSE field to demonstrate how end users can make a choice/see the reality using out-of-name metadata. But there is quite frankly no *need* for -gbin and -bin The only real /technical/ reason we have both -bin and -gbin is it avoids the binary version competing for a name with the source-built version. That is, if there is a "-bin" package, its viable some day there may be a non "-bin" package, and that they may both be available side-by-side and you may wish to choose between them. But "-gbin" and "-bin" coexisting side-by side is a usecase I can't see being useful to anybody.
pgpCBAlsKLSRn.pgp
Description: OpenPGP digital signature
