Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Dale <rdalek1967@...>
Subject: Re: RFC: deprecate /usr/share/doc/$PF
Date: Sun, 18 Dec 2011 22:48:27 -0600
Ulrich Mueller wrote:
>>>>>> On Sun, 18 Dec 2011, Alexandre Rostovtsev wrote:
>>> Can we please avoid the bloat of another directory level here?
>>> ${CATEGORY}/${PN} will be even longer than ${PF} in most cases.
>> The problem is that ($PN, $CATEGORY) pairs are not unique. Think of
>> x11-terms/terminal:0 and gnustep-apps/terminal:0, or
>> app-misc/beagle:0 and sci-libs/beagle:0, or app-misc/nut:0 and
>> sys-power/nut:0. I could not think of any better solution than using
>> $CATEGORY/$PN-$SLOT.
> Thinking about it a little more, I believe that ${CATEGORY} shouldn't
> appear anywhere in the path of installed files, for the following
> reasons:
>
> 1. Users may not know the category of a package, therefore it's not
>     obvious for them where to find its documentation. (Think of it from
>     the perspective of a user on a multiuser system, who didn't install
>     the packages on that system.) OTOH, the name of the package (PN) is
>     obvious in most cases, since it will coincide with the upstream
>     name.
>
> 2. It doesn't play well with bash completion. When searching for
>     documentation of a specific package (and only knowing PN), one can
>     currently type the pathname up to PN and press tab which will
>     complete PVR. With CATEGORY _before_ PN this would no longer work.
>
> 3. CATEGORY and SLOT are Gentoo specific, related to the way how we
>     organise our packages. Neither of them should appear in the
>     directory structure of installed packages. The problems related to
>     package and slot moves (where CATEGORY or SLOT change) also show
>     that something is wrong with the approach. (BTW, in the current
>     system, PR is also Gentoo specific. It doesn't suffer from problems
>     with package moves though.)
>
>> Do you have a better proposal that does not rely on $PVR?
> Leave things as they are. It's not perfect, but IMHO your approach
> would create at least as many problems as it would solve.
> Alternatively, a minimal solution would be to drop only ${PR}, i.e.
> install documentation under /usr/share/doc/${P}.
>
> Ulrich
>
>

I like the logic in #1 as a user.  What if two packages have the same 
name but different categories tho?  It is rare but I do run into this 
from time to time.  I try to emerge something but am informed by emerge 
that I have to include the category for emerge to know exactly which 
package I want installed.

I do agree that docs are sometimes hard to find.  The only way I have 
any success is equery files <package name> then see where it put them or 
if there is none to find.

Back to my hole.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"



Replies:
Re: RFC: deprecate /usr/share/doc/$PF
-- Duncan
References:
RFC: deprecate /usr/share/doc/$PF
-- Alexandre Rostovtsev
Re: RFC: deprecate /usr/share/doc/$PF
-- Ulrich Mueller
Re: RFC: deprecate /usr/share/doc/$PF
-- Ulrich Mueller
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFC: deprecate /usr/share/doc/$PF
Next by thread:
Re: RFC: deprecate /usr/share/doc/$PF
Previous by date:
Re: RFC: deprecate /usr/share/doc/$PF
Next by date:
Re: RFC: deprecate /usr/share/doc/$PF


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.