From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?
Date: Tue, 21 Sep 2004 03:47:49 -0700 [thread overview]
Message-ID: <pan.2004.09.21.10.47.48.152334@cox.net> (raw)
In-Reply-To: 200409202117.34236.carlo@gentoo.org
Carsten Lohrke posted <200409202117.34236.carlo@gentoo.org>, excerpted
below, on Mon, 20 Sep 2004 21:17:26 +0200:
> #Chapter 4. The /usr Hierarchy
>
> #Purpose
>
> #/usr is the second major section of the filesystem. /usr is shareable,
> #read-only data. That means that /usr should be shareable between various
> #FHS-compliant hosts and must not be written to. Any information that is
> #host-specific or varies with time is stored elsewhere.
>
> #Large software packages must not use a direct subdirectory under the /usr
> #hierarchy
>
> O.k., that doesn't forbid to add another directory and to use this one as a
> new base, but it still doesn't make sense to me. I see this formulation more
> as a gap in the standard. Either unintended or as a backwards compatibility
> thing to get everyone into the boat.
OK, since nobody else has brought this up, I must be reading something
wrong, but I don't see what the problem is here. (I also repeat myself a
bit below. However, it's so obvious here, I find it difficult to believe
that someone else hasn't seen it either. Yet the fact remains I
haven't seen it mentioned yet, in what has become a rather long thread.
That must mean it's non-obvious, despite what it seems here, so excuse a
bit of belaboring of the point in my attempt to make it equally obvious
to others! <g>)
As I see it, we are NOT putting "large packages" directly under /usr,
because the "large packages" in question are versioned (slotted per
individual directory) and under /kde. As I read the spec, /usr/kde is
already a level of indirection, because our packages are (perfectly
logically, it seems to me) laid out beneath /usr/kde and not directly in
/usr.
IOW, the way I read it, /usr/kde-3.3 would be a violation, but
/usr/kde/3.3 isn't, because it's already a level of indirection. Just
because we've chosen to only put KDE related packages at that specific
case of the indirection level means nothing. The packages are STILL not
directly under /usr.
Now, I WOULD have an issue with /usr/kde-3.3, and /usr/kde-3.2, and
/usr/kde-4.0, etc (and noting that with other distribs there'd likely be
only a single version-slot under /usr/kde). That's just a ridiculous
proliferation directly under /usr and I'm sure everyone would agree.
However, as has already come up, given the large (both in size and in
dependencies) tree that is KDE, I see nothing at all wrong with putting
that dir itself (not the packages or slots in it) directly under /usr, nor
can I see how it conflicts with the quoted rules above.
Again, for those distribs without multiple KDE slots, a single /usr/kde
would indeed be a violation, as it's just a single (meta-)package.
However, the fact that we've chosen to group a very large package set that
under our (meta-)distribution could reasonably be several multiples of the
size of /most/ distribution's kde, under a /usr direct subdir with each
instance of our multiples below that, doesn't seem to me to be in conflict
with the FHS at all. Again, as others have pointed out in other contexts,
there's nothing wrong with adding /more/ dirs. We just have to have the
basics and observe the rules about what goes in them.
Putting it another way, we've already proposed /usr/packages. Now, if we
got a whole bunch of packages, there'd be nothing wrong with splitting
that into say /usr/pkg-a-m, and /usr/pkg-n-z, right? OK, what if there
were more k- packages than all the others combined? There wouldn't be a
problem with /usr/pkg-but-k and /usr/pkg-k, right?
We've just done gone the logical next step. Because KDE is multi-slotted,
and with KDE as big as it is already and the slotting essentially
multiplying that X times, we've just created what is essentially
/usr/pkg-kde, only without the pkg- part. I still contend that we aren't
putting our packages directly under /usr, as each package is in fact in a
slot in kde in /usr. Where's the FHS violation? I can't see it?
--
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2004-09-21 10:48 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-19 19:50 [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? Thomas Weidner
2004-09-19 19:52 ` Ciaran McCreesh
2004-09-19 20:07 ` Mike Frysinger
2004-09-19 20:06 ` Dan Armak
2004-09-19 20:07 ` Joshua J. Berry
2004-09-19 20:13 ` Ciaran McCreesh
2004-09-19 20:16 ` Dan Armak
2004-09-19 20:26 ` Joshua J. Berry
2004-09-19 20:29 ` Ciaran McCreesh
2004-09-19 22:23 ` Joshua J. Berry
2004-09-20 8:41 ` Paul de Vrieze
2004-09-19 20:37 ` Dan Armak
2004-09-19 21:23 ` Malte S. Stretz
2004-09-19 23:38 ` Armando Di Cianno
2004-09-20 8:48 ` Paul de Vrieze
2004-09-20 9:47 ` Malte S. Stretz
2004-09-20 15:56 ` Armando Di Cianno
2004-09-20 19:52 ` Malte S. Stretz
2004-09-20 15:40 ` Dan Armak
2004-09-20 18:30 ` Paul de Vrieze
2004-09-20 19:45 ` Malte S. Stretz
2004-09-19 22:35 ` Joshua J. Berry
2004-09-20 4:10 ` Dan Armak
2004-09-20 4:27 ` Mike Frysinger
2004-09-20 4:47 ` Luke-Jr
2004-09-20 6:09 ` Joshua J. Berry
2004-09-20 9:05 ` Paul de Vrieze
2004-09-20 15:55 ` Sami Samhuri
2004-09-20 16:22 ` Carsten Lohrke
2004-09-20 16:36 ` Malte S. Stretz
2004-09-20 16:44 ` Dan Armak
2004-09-20 17:19 ` Malte S. Stretz
2004-09-20 17:36 ` Dan Armak
2004-09-20 22:58 ` foser
2004-09-20 17:42 ` Carsten Lohrke
2004-09-20 16:37 ` Dan Armak
2004-09-20 17:35 ` Carsten Lohrke
2004-09-20 18:52 ` Paul de Vrieze
2004-09-20 19:17 ` Carsten Lohrke
2004-09-21 10:47 ` Duncan [this message]
2004-09-21 11:02 ` [gentoo-dev] " Duncan
2004-09-21 12:05 ` Carsten Lohrke
2004-09-21 4:58 ` Joel Konkle-Parker
2004-09-21 9:49 ` Paul de Vrieze
2004-09-20 7:49 ` [gentoo-dev] " Simon Watson
2004-09-19 20:09 ` Paul de Vrieze
2004-09-28 2:51 ` [gentoo-dev] " John Croisant
2004-09-28 8:19 ` Paul de Vrieze
2004-09-28 9:24 ` Peter Ruskin
2004-09-28 9:37 ` Paul de Vrieze
2004-09-28 20:32 ` John Croisant
2004-09-29 9:07 ` Paul de Vrieze
2004-09-19 21:55 ` [gentoo-dev] " Luke-Jr
2004-09-19 23:06 ` [gentoo-dev] " Thomas Weidner
2004-09-20 0:03 ` Luke-Jr
2004-09-20 0:55 ` Ciaran McCreesh
2004-09-20 3:50 ` Luke-Jr
2004-09-21 5:10 ` Joel Konkle-Parker
2004-09-21 17:29 ` Helmar Wieland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2004.09.21.10.47.48.152334@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox