On Mon, 17 Oct 2016 09:39:25 -0400 "William L. Thomson Jr." <wlt...@o-sinc.com> wrote: > > > PROPERTIES="binary:upstream" > > > > or > > > > PROPERTIES="binary:gentoo" > > > > Assuming the right tooling, this allows a way to "canonically" define > > what the type of binary is, and allow people to make whatever choices, > > including automated rules. > > That is one way to go, but one would have to spend time to find out the > source.
Here is where it would be nice to have a printf style format argument for portage where we can customize output listing. Then you could just do like you'd do with git and add custom user defined spice. Or like, as I mentioned other places, you could indicate to portage to restrict options by default based on this property. > > After you do that, you can deem a *convention* of adding -bin suffixes, > > but instead of making it a "rule", make it simply a pattern that people > > can follow if their package indicates they need suffixing. > > Patterns rather than rules/policies lead to inconsistent practice which is > the > case now. > > > This means: > > > > 1. "bin" packages don't need "-bin" suffixes, because metadata will convey > > it 2. ... however, you can still use a "-bin" suffix and its encouraged. > > That doesn't really make sense with 1, saying you do not need -bin suffix but > then it is encouraged? Because it really just doesn't make sense for some packages to be -bin, some things will never exist in source form. Opera, Skype, there's no need to state them as -bin, there will be nothing else for the forseeable future. Encouraging the use of -bin says <<look at what you're doing, and see if it makes sense for what you're doing, and by all means, if it looks like there might be a usecase for an ability to differentiate between "-bin", and not, by all means, go ahead, but you don't have to>> And there's no benefit to anyone to go pkg-move them all to have "-bin" on the end. They've already got it installed. Its just noise without an actual technical need. > Which leads to more inconsistency in tree. The idea is to have it consistent > per policy and not leaving naming up to a maintainer. Inconsistency is only "bad" if the reality underneath is itself, consistent. Forcing arbitrary consistency where the reality underneath is fluid doesn't really do anything for us. But the "need" to have "-bin" suffixing is really a case-by-case basis thing, not a global axiom. If you're *going* to differentiate, "-bin" is the recommended standard way to differentiate, and you should use no other suffix for differentiation. But if there's no need for differentiation, don't differentiate for the sake of doing so. ( and this "if there's a need to differentiate" covers all your suggested cases with variants and testing, because those are theoretical "needs", but not all packages need these things, and the tree would be anarchy if we applied that logic to every package ... every version of every package would be slotted "just in case!" ) > > Do you have any ideas how to reduce that and get others to help package > things > that other stick in tree as binary rather than from source? > The growth of bins in tree are not something you can fix with policy. All policy will do is make their presence more well known at best ( and this can be achieved anyway without needing -bin suffixes on everything ) The "Actual Problems" will still require people to do the work, for proprietary software to die, and for upstream to stop packaging their software like everyone is downloading it from source forge and running it from their windows desktop. Given all that ..... I don't see bin's evaporating any time soon. Not at least without a "no bins at any cost" policy, which would only harm our users.
pgpb3cdjgmcJY.pgp
Description: OpenPGP digital signature
