1 |
On Sun, 3 Feb 2013 11:19:24 +0100 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> This is a common error, especially in my ebuilds or those based on |
5 |
> mine. It gives a bunch of collisions, so dying here seems to be |
6 |
> acceptable while eqawarn is easy to miss. |
7 |
> --- |
8 |
> gx86/eclass/distutils-r1.eclass | 4 ++++ |
9 |
> 1 file changed, 4 insertions(+) |
10 |
> |
11 |
> diff --git a/gx86/eclass/distutils-r1.eclass |
12 |
> b/gx86/eclass/distutils-r1.eclass index 27730f5..13d65b5 100644 |
13 |
> --- a/gx86/eclass/distutils-r1.eclass |
14 |
> +++ b/gx86/eclass/distutils-r1.eclass |
15 |
> @@ -367,6 +367,10 @@ distutils-r1_python_install() { |
16 |
> |
17 |
> esetup.py install "${flags[@]}" --root="${root}" "${@}" |
18 |
> |
19 |
> + if [[ -d ${root}$(python_get_sitedir)/tests ]]; then |
20 |
> + die "Package installs 'tests' package, file |
21 |
> collisions likely." |
22 |
> + fi |
23 |
> + |
24 |
> if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then |
25 |
> _distutils-r1_rename_scripts "${root}" |
26 |
> _distutils-r1_merge_root "${root}" "${D}" |
27 |
|
28 |
Actually I don't like it. I did a 'fix' like this to a package in a |
29 |
more rare instance concerning building of docs, but the Rx was to |
30 |
abort and call die and tell the user to start again. The chief critic |
31 |
of this concluded I didn't know what I was doing, but then he's known |
32 |
for his prolific and indiscriminant use of hyperbole. The 'better' |
33 |
solution was to indeed to correct the underlying flaw and and get on |
34 |
with emerging the package. The practice of 'abort and start again' is, |
35 |
I admit, unsavoury at best. |
36 |
|
37 |
Given that this is a relatively common error, let's get a 'clear |
38 |
picture' of the status of the presence of the relatively common |
39 |
instance test folders and suites in python packages. There are some |
40 |
that install them and some that don't, so we're forced to chase a |
41 |
'moving target'. Can we decide categorically that test suites need and |
42 |
ought not be installed in python packages, or do we have to water it |
43 |
down with "Oh it depends on these dozens of possibilities and those |
44 |
ones over there"? This creates a myriad of scenarios of uncertainty. |
45 |
|
46 |
Step 1. Make the target still |
47 |
|
48 |
Step 2. Once the target is still, then deal with it accordingly; |
49 |
install them in a collision free fashion, or delete them once and for |
50 |
all if we can declare then un-needed. The latter has quite a bit going |
51 |
for it. |
52 |
|
53 |
Step 3. Make potential critics like the anonymous dev previously and |
54 |
obliquely cited forever silent, and get on with emerging the package. |
55 |
|
56 |
-- |
57 |
kind regards |
58 |
|
59 |
Ian Delaney |