Re: [gentoo-dev] Package file name requirement for binary ebuilds

[Kent Fredric]

On Mon, 17 Oct 2016 09:39:25 -0400
"William L. Thomson Jr." <wlt-ml@××××××.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.