1 |
On Wed, 10 Sep 2014 13:56:04 +0000 |
2 |
hasufell <hasufell@g.o> wrote: |
3 |
|
4 |
> Tom Wijsman: |
5 |
> > On Tue, 09 Sep 2014 19:12:28 +0000 |
6 |
> > hasufell <hasufell@g.o> wrote: |
7 |
> > |
8 |
> >> Jauhien Piatlicki: |
9 |
> >>> |
10 |
> >>> When I accept ~arch I expect that no live ebuilds will be built. I |
11 |
> >>> think other gentoo users expect the same. |
12 |
> >> |
13 |
> >> Just because users are used to it doesn't make it better. |
14 |
> > |
15 |
> > How does it "make it better" for users that are used to what works |
16 |
> > well? |
17 |
> |
18 |
> It improves usability by providing additional information. |
19 |
|
20 |
Usability is not to be found in information that is subject to change. |
21 |
|
22 |
> >>> Emerging live ebuild usually is quite a risky thing, so hiding |
23 |
> >>> such stuff behind dropped keywords is quite reasonable. |
24 |
> >> |
25 |
> >> That's why you can mask them. |
26 |
> > |
27 |
> > Masking is for packages that are known to be broken, not for risks. |
28 |
> |
29 |
> PMS doesn't specify what exactly package.mask is for, so scm ebuilds |
30 |
> is a perfectly valid use case, unless you can come up with an |
31 |
> alternative that is not wrong like empty KEYWORDS. |
32 |
|
33 |
That something is not in PMS does not make it a valid use case; the |
34 |
Portage tree is subject to more specifications, like for example that |
35 |
the devmanual has a very specific paragraph on this case: |
36 |
|
37 |
"CVS ebuilds must be either with empty KEYWORDS or package.masked (but |
38 |
not both). Empty KEYWORDS are strongly preferred. This applies to |
39 |
"live" ebuilds (-9999) and to ebuilds that extract a static revision |
40 |
but still use CVS for fetching." |
41 |
|
42 |
http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources |
43 |
|
44 |
We can also find more about empty keywords: |
45 |
|
46 |
"No keyword: If a package has no keyword for a given arch, it means it |
47 |
is not known whether the package will work, or that insufficient |
48 |
testing has occurred for ~arch." |
49 |
|
50 |
http://devmanual.gentoo.org/keywording |
51 |
|
52 |
So, both quotes reveal that empty keywords fit very well; package.mask |
53 |
rather fits when there is a good reason to it, especially since the |
54 |
idea of QA is to keep package.mask maintainable by limiting its length. |
55 |
|
56 |
In doing so, QA can keep an eye on what is broken; which allows either |
57 |
fixing or removing ebuilds that stay there too long. In this context, a |
58 |
masked live ebuild would be interpreted as a live ebuild that fails to |
59 |
fetch, compile or run for a prolonged time; eg. due to an inactive or |
60 |
dead upstream, or an upstream that refuses to support that broken part. |
61 |
|
62 |
> >> The same flawed logic of empty KEYWORDS could actually be applied |
63 |
> >> to any ebuild variable. |
64 |
> >> You say "we can't test if it works for all these architectures |
65 |
> >> reliably and for every single commit". |
66 |
> >> Yeah, same goes for dependencies, license and even the description. |
67 |
> >> Because it's a live ebuild, all of them can change. KEYWORDS is no |
68 |
> >> special exception. |
69 |
> > |
70 |
> > KEYWORDS is a special exception because it involves arch testing. |
71 |
> |
72 |
> Yes, and you hide this information from the user. |
73 |
|
74 |
Information that is a given; as known, live ebuilds miss arch testing. |