From: pk <peterk2@coolmail.se>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] systemd installation location
Date: Mon, 30 Sep 2013 08:24:28 +0200 [thread overview]
Message-ID: <5249191C.6040306@coolmail.se> (raw)
In-Reply-To: <CAG2nJkOZvHT5TxMYd+W5GOn-PTD-Y4z+gZQR+VF_jm2UWjmeHQ@mail.gmail.com>
On 2013-09-30 04:05, Mark David Dumlao wrote:
> It's true that it's nice to have a semblance of order where different parts go.
> But "all libraries and binaries in /usr" is also a semblance of order. You don't
> separate stuff for the sake of separating stuff. You separate them because you
> have a good reason to separate them. It turns out that there isn't a good reason
> to separate them, and that there's no way to predictably separate them.
>
> Mushing them together isn't just a stop-gap or good-enough solution. The
> idea of keeping system-critical separate from non-critical was not maintainable
> in the long run to begin with.
So what you're saying is that everything in /usr is system-critical? I
have gimp installed in /usr... I don't see a need to start gimp at boot
time. Maybe we should classify frozen-bubble as system-critical as well
(it's also in /usr)?
Seriously, boot-critical would be something that the system cannot *boot
without*, which belongs in /. Everything else should be in /usr, i.e.
non-boot-critical. How hard is it to start *non-boot* (system) critical
*after* boot (things like sshd)? I do that today...
> are the same. Distro packagers, however, have to decide for 100% of the cases.
> So they're going to end up making weird decisions that are easy for you to
> second-guess but are actually tough.
That's only true for binary distros.
> If you want to solve the "hard problem", you want to create a tool that
> will automate / and /usr migrations. Portage has to be aware of the tool
What's wrong with using autotools? I really don't see why you need it to
be dynamic. In Gentoo you install stuff once for every version (or if
you change use flag). Why invent stuff/complicate matters when you don't
need to?
Best regards
Peter K
next prev parent reply other threads:[~2013-09-30 6:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-29 19:52 [gentoo-user] systemd installation location William Hubbs
2013-09-30 0:54 ` Daniel Campbell
2013-09-30 1:17 ` Mark David Dumlao
2013-09-30 1:22 ` Daniel Campbell
2013-09-30 1:51 ` Mark David Dumlao
2013-09-30 2:01 ` Daniel Campbell
2013-09-30 2:25 ` Mark David Dumlao
2013-09-30 2:31 ` Daniel Campbell
2013-09-30 4:13 ` Pandu Poluan
2013-09-30 5:08 ` Mark David Dumlao
2013-09-30 1:40 ` Mark David Dumlao
2013-09-30 1:50 ` Daniel Campbell
2013-09-30 2:05 ` Mark David Dumlao
2013-09-30 2:15 ` Daniel Campbell
2013-09-30 2:42 ` Mark David Dumlao
2013-09-30 8:07 ` Neil Bothwick
2013-09-30 6:24 ` pk [this message]
2013-09-30 6:45 ` Alan McKinnon
2013-09-30 22:14 ` pk
2013-09-30 22:43 ` Neil Bothwick
2013-10-01 6:16 ` Alan McKinnon
2013-10-01 19:59 ` pk
2013-09-30 16:06 ` [gentoo-user] " Martin Vaeth
2013-09-30 17:47 ` [gentoo-user] " Mark David Dumlao
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=5249191C.6040306@coolmail.se \
--to=peterk2@coolmail.se \
--cc=gentoo-user@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