| 1 |
On Monday, October 17, 2016 9:46:12 PM EDT Kent Fredric wrote: |
| 2 |
> On Mon, 17 Oct 2016 03:41:13 -0400 |
| 3 |
> |
| 4 |
> "William L. Thomson Jr." <wlt-ml@××××××.com> wrote: |
| 5 |
> > To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin. NO more. |
| 6 |
> |
| 7 |
> It would be far better to simply have a PROPERTIES field in ebuilds or |
| 8 |
> somesuch: |
| 9 |
|
| 10 |
A -bin package is coming in as a dependency. How you do you know where it came |
| 11 |
from? |
| 12 |
|
| 13 |
> PROPERTIES="binary:upstream" |
| 14 |
> |
| 15 |
> or |
| 16 |
> |
| 17 |
> PROPERTIES="binary:gentoo" |
| 18 |
> |
| 19 |
> Assuming the right tooling, this allows a way to "canonically" define |
| 20 |
> what the type of binary is, and allow people to make whatever choices, |
| 21 |
> including automated rules. |
| 22 |
|
| 23 |
That is one way to go, but one would have to spend time to find out the source. |
| 24 |
|
| 25 |
> After you do that, you can deem a *convention* of adding -bin suffixes, |
| 26 |
> but instead of making it a "rule", make it simply a pattern that people |
| 27 |
> can follow if their package indicates they need suffixing. |
| 28 |
|
| 29 |
Patterns rather than rules/policies lead to inconsistent practice which is the |
| 30 |
case now. |
| 31 |
|
| 32 |
> This means: |
| 33 |
> |
| 34 |
> 1. "bin" packages don't need "-bin" suffixes, because metadata will convey |
| 35 |
> it 2. ... however, you can still use a "-bin" suffix and its encouraged. |
| 36 |
|
| 37 |
That doesn't really make sense with 1, saying you do not need -bin suffix but |
| 38 |
then it is encouraged? |
| 39 |
|
| 40 |
> 3. |
| 41 |
> packages that end with '-bin' suffixes, but *arent* binaries can be clearly |
| 42 |
> identified as such via metdata. ( Imagine something like |
| 43 |
> dev-util/recycle-bin ) |
| 44 |
|
| 45 |
The main issue I see with metadata is time. If your updating a system or |
| 46 |
several, a new -bin shows up potentially. You will have to spend time to |
| 47 |
determine the type of bin. |
| 48 |
|
| 49 |
It also does not provide any "notification" to others that hey, this can be |
| 50 |
packaged from source. |
| 51 |
|
| 52 |
> 4. any additional finessing of names to indicate what is going on can |
| 53 |
> be decided by the maintainers in question, on a "as necessary basis" |
| 54 |
|
| 55 |
Which leads to more inconsistency in tree. The idea is to have it consistent |
| 56 |
per policy and not leaving naming up to a maintainer. |
| 57 |
|
| 58 |
> This means instead of "require this pattern" which will eventually |
| 59 |
> result in useless chaos as packages rename all over the place, it will |
| 60 |
> also avoid "require this pattern" where its not needed. ( neither |
| 61 |
> www-client/opera, www-client/opera-developer, or www-client/opera-beta |
| 62 |
> are source based, they're all binaries, unpacked from .deb's for crying |
| 63 |
> out loud ) |
| 64 |
|
| 65 |
Then they should all have the -bin suffix. Already showing deviation from that |
| 66 |
while other packages have it. Exactly the inconsistency a policy would |
| 67 |
address. |
| 68 |
|
| 69 |
> And we don't want to embrace visibly the idea that "free for all |
| 70 |
> binaries!!!!" by having too many -bin packages in tree. |
| 71 |
|
| 72 |
Part of the idea is to prevent the growing -bins in tree.... |
| 73 |
|
| 74 |
Do you have any ideas how to reduce that and get others to help package things |
| 75 |
that other stick in tree as binary rather than from source? |
| 76 |
|
| 77 |
-- |
| 78 |
William L. Thomson Jr. |
Archives