1 |
Ulrich Mueller wrote: |
2 |
>>>>>> On Sun, 18 Dec 2011, Alexandre Rostovtsev wrote: |
3 |
>>> Can we please avoid the bloat of another directory level here? |
4 |
>>> ${CATEGORY}/${PN} will be even longer than ${PF} in most cases. |
5 |
>> The problem is that ($PN, $CATEGORY) pairs are not unique. Think of |
6 |
>> x11-terms/terminal:0 and gnustep-apps/terminal:0, or |
7 |
>> app-misc/beagle:0 and sci-libs/beagle:0, or app-misc/nut:0 and |
8 |
>> sys-power/nut:0. I could not think of any better solution than using |
9 |
>> $CATEGORY/$PN-$SLOT. |
10 |
> Thinking about it a little more, I believe that ${CATEGORY} shouldn't |
11 |
> appear anywhere in the path of installed files, for the following |
12 |
> reasons: |
13 |
> |
14 |
> 1. Users may not know the category of a package, therefore it's not |
15 |
> obvious for them where to find its documentation. (Think of it from |
16 |
> the perspective of a user on a multiuser system, who didn't install |
17 |
> the packages on that system.) OTOH, the name of the package (PN) is |
18 |
> obvious in most cases, since it will coincide with the upstream |
19 |
> name. |
20 |
> |
21 |
> 2. It doesn't play well with bash completion. When searching for |
22 |
> documentation of a specific package (and only knowing PN), one can |
23 |
> currently type the pathname up to PN and press tab which will |
24 |
> complete PVR. With CATEGORY _before_ PN this would no longer work. |
25 |
> |
26 |
> 3. CATEGORY and SLOT are Gentoo specific, related to the way how we |
27 |
> organise our packages. Neither of them should appear in the |
28 |
> directory structure of installed packages. The problems related to |
29 |
> package and slot moves (where CATEGORY or SLOT change) also show |
30 |
> that something is wrong with the approach. (BTW, in the current |
31 |
> system, PR is also Gentoo specific. It doesn't suffer from problems |
32 |
> with package moves though.) |
33 |
> |
34 |
>> Do you have a better proposal that does not rely on $PVR? |
35 |
> Leave things as they are. It's not perfect, but IMHO your approach |
36 |
> would create at least as many problems as it would solve. |
37 |
> Alternatively, a minimal solution would be to drop only ${PR}, i.e. |
38 |
> install documentation under /usr/share/doc/${P}. |
39 |
> |
40 |
> Ulrich |
41 |
> |
42 |
> |
43 |
|
44 |
I like the logic in #1 as a user. What if two packages have the same |
45 |
name but different categories tho? It is rare but I do run into this |
46 |
from time to time. I try to emerge something but am informed by emerge |
47 |
that I have to include the category for emerge to know exactly which |
48 |
package I want installed. |
49 |
|
50 |
I do agree that docs are sometimes hard to find. The only way I have |
51 |
any success is equery files <package name> then see where it put them or |
52 |
if there is none to find. |
53 |
|
54 |
Back to my hole. |
55 |
|
56 |
Dale |
57 |
|
58 |
:-) :-) |
59 |
|
60 |
-- |
61 |
I am only responsible for what I said ... Not for what you understood or how you interpreted my words! |
62 |
|
63 |
Miss the compile output? Hint: |
64 |
EMERGE_DEFAULT_OPTS="--quiet-build=n" |