Gentoo Archives: gentoo-dev

From: Kent Fredric <kentnl@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Package file name requirement for binary ebuilds
Date: Mon, 17 Oct 2016 15:03:27
Message-Id: 20161018040250.600d900e@katipo2.lan
In Reply to: Re: [gentoo-dev] Package file name requirement for binary ebuilds by "William L. Thomson Jr."
1 On Mon, 17 Oct 2016 09:39:25 -0400
2 "William L. Thomson Jr." <wlt-ml@××××××.com> wrote:
3 >
4 > > PROPERTIES="binary:upstream"
5 > >
6 > > or
7 > >
8 > > PROPERTIES="binary:gentoo"
9 > >
10 > > Assuming the right tooling, this allows a way to "canonically" define
11 > > what the type of binary is, and allow people to make whatever choices,
12 > > including automated rules.
13 >
14 > That is one way to go, but one would have to spend time to find out the source.
16 Here is where it would be nice to have a printf style format argument for portage
17 where we can customize output listing.
19 Then you could just do like you'd do with git and add custom user defined spice.
21 Or like, as I mentioned other places, you could indicate to portage to restrict
22 options by default based on this property.
24 > > After you do that, you can deem a *convention* of adding -bin suffixes,
25 > > but instead of making it a "rule", make it simply a pattern that people
26 > > can follow if their package indicates they need suffixing.
27 >
28 > Patterns rather than rules/policies lead to inconsistent practice which is the
29 > case now.
30 >
31 > > This means:
32 > >
33 > > 1. "bin" packages don't need "-bin" suffixes, because metadata will convey
34 > > it 2. ... however, you can still use a "-bin" suffix and its encouraged.
35 >
36 > That doesn't really make sense with 1, saying you do not need -bin suffix but
37 > then it is encouraged?
39 Because it really just doesn't make sense for some packages to be -bin,
40 some things will never exist in source form. Opera, Skype, there's no
41 need to state them as -bin, there will be nothing else for the
42 forseeable future.
44 Encouraging the use of -bin says <<look at what you're doing, and see
45 if it makes sense for what you're doing, and by all means, if it looks
46 like there might be a usecase for an ability to differentiate between
47 "-bin", and not, by all means, go ahead, but you don't have to>>
49 And there's no benefit to anyone to go pkg-move them all to have "-bin"
50 on the end. They've already got it installed. Its just noise without an
51 actual technical need.
53 > Which leads to more inconsistency in tree. The idea is to have it consistent
54 > per policy and not leaving naming up to a maintainer.
56 Inconsistency is only "bad" if the reality underneath is itself,
57 consistent.
59 Forcing arbitrary consistency where the reality underneath is fluid
60 doesn't really do anything for us.
62 But the "need" to have "-bin" suffixing is really a case-by-case basis thing,
63 not a global axiom.
65 If you're *going* to differentiate, "-bin" is the recommended standard
66 way to differentiate, and you should use no other suffix for
67 differentiation.
69 But if there's no need for differentiation, don't differentiate for the
70 sake of doing so.
72 ( and this "if there's a need to differentiate" covers all your
73 suggested cases with variants and testing, because those are
74 theoretical "needs", but not all packages need these things, and the
75 tree would be anarchy if we applied that logic to every package ...
76 every version of every package would be slotted "just in case!" )
78 >
79 > Do you have any ideas how to reduce that and get others to help package things
80 > that other stick in tree as binary rather than from source?
81 >
83 The growth of bins in tree are not something you can fix with policy.
85 All policy will do is make their presence more well known at best ( and
86 this can be achieved anyway without needing -bin suffixes on everything
87 )
89 The "Actual Problems" will still require people to do the work, for
90 proprietary software to die, and for upstream to stop packaging their
91 software like everyone is downloading it from source forge and running
92 it from their windows desktop.
94 Given all that ..... I don't see bin's evaporating any time soon.
96 Not at least without a "no bins at any cost" policy, which would only
97 harm our users.