Gentoo Archives: gentoo-dev

From: Dale <rdalek1967@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: deprecate /usr/share/doc/$PF
Date: Mon, 19 Dec 2011 04:49:08
Message-Id: 4EEEC21B.6070602@gmail.com
In Reply to: Re: [gentoo-dev] RFC: deprecate /usr/share/doc/$PF by Ulrich Mueller
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"

Replies

Subject Author
[gentoo-dev] Re: RFC: deprecate /usr/share/doc/$PF Duncan <1i5t5.duncan@×××.net>