1 |
On Tue, 13 Sep 2016 19:49:22 -0400 |
2 |
Michael Orlitzky <mjo@g.o> wrote: |
3 |
|
4 |
> > Patches: |
5 |
> > * Wildcard patching: Usually i use my "patchtest" script for finding |
6 |
> > obsolete patches and while it still finds lots of false |
7 |
> > positives i also saw a rather odd patching style: Patching via |
8 |
> > wildcards. For example: |
9 |
> > epatch "${FILESDIR}"/${P}*.patch |
10 |
> > I looks a bit unsafe to use wildcards for patching, but I |
11 |
> > couldn't find anything which forbids it. Would be nice to know |
12 |
> > if that is ok. |
13 |
> |
14 |
> Please file a bug and tell people not to do that. If they ever need to |
15 |
> add a new patch, it would affect old stable ebuilds and violate our |
16 |
> policy on the matter. |
17 |
> |
18 |
> It would be nice if we could add this check to repoman; however, some |
19 |
> wildcard constructs are safe. For example, if we're pulling in a bunch |
20 |
> of Debian patches in SRC_URI, it makes sense to apply them all. The |
21 |
> SRC_URI is guaranteed not to change out from under us, unlike the |
22 |
> contents of FILESDIR. |
23 |
|
24 |
|
25 |
Clearly the problem is not the use of wildcards in "epatch", but the use of wildcards |
26 |
anywhere in conjunction with "${FILESDIR}" |
27 |
|
28 |
For instance, if they were not patches, but blobs of shell script ala eblits, you might |
29 |
see the following happen: |
30 |
|
31 |
for i in "${FILESDIR}"/${P}*.sh"; do |
32 |
source $i |
33 |
done |
34 |
|
35 |
This would also be a QA Violation because it would be just as likely to be broken by bumps |
36 |
as patches. |
37 |
|
38 |
> |
39 |
> > * scripts in FILESDIR: In some packages i found scripts which doesn't |
40 |
> > get used by the ebuild, but is probably used for generating |
41 |
> > patches/tarballs. Should i file a bugs about them as i though the |
42 |
> > FILESDIR should be only used for patches. Wouldn't be |
43 |
> > /etc/portage/scripts the perfect place for such scripts? |
44 |
> |
45 |
> |
46 |
> If they're not used by the tree, they probably don't belong in the tree, |
47 |
> but maybe I lack imagination. Can you give a few examples? |
48 |
|
49 |
I agree if that if the scripts in question aren't used by the ebuilds, then |
50 |
grounds to keep them included are weakened. |
51 |
|
52 |
However, It rather depends on what those scripts are doing and how important |
53 |
it is to keep those scripts synchronised between developers working on a given thing. |
54 |
|
55 |
If for instance a given specific ebuild needs some scripts to generate parts of ebuilds |
56 |
in a consistent way, but the result of it is static code that is placed in the ebuild, |
57 |
then under the grounds of "ebuild doesn't use it", it would be removed. |
58 |
|
59 |
But that script has no other place to be stored that makes sense, because putting it |
60 |
in an isolated repo just hides the existence of that script, and discourages its |
61 |
use when its use should be encouraged. |
62 |
|
63 |
And putting it somewhere other than gentoo.git means there's another step required |
64 |
by maintainers to keep the tree "updated" and coherent, and reduces another place |
65 |
failures can leak in if they forget to sync the independent repository. |
66 |
|
67 |
Thus, it introduces a conflict of purpose: |
68 |
|
69 |
1. We need certain things to be centralised and "in the repo" for the point of |
70 |
maintainership and coherence. |
71 |
|
72 |
2. We desire things that users don't strictly need don't get replicated where |
73 |
they're not wanted. |
74 |
|
75 |
A dogma of keeping the tree clean thus penalises how developers work, and makes |
76 |
it harder to produce the quality we want to deliver to users, but having them |
77 |
in tree reduces the quality we deliver to users. |
78 |
|
79 |
Though, to be pragmatic, the burden of having those scripts present in tree |
80 |
seems more a cosmetic problem from the users perspective, while removing them |
81 |
produces a functional problem. |
82 |
|
83 |
So I'd reason that as long as these scripts follow policy of not being |
84 |
too large, and they're not abused everywhere, the pragmatic view is to permit |
85 |
them staying. |