mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Ladislav Michl <ladis@linux-mips.org>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] /usr merge
Date: Wed, 12 Apr 2017 14:06:19 +0200	[thread overview]
Message-ID: <20170412120618.tuaikcgtxma7iap7@lenoch> (raw)
In-Reply-To: <20170412092435.6co6bltno2e7qzzr@pengutronix.de>

On Wed, Apr 12, 2017 at 11:24:35AM +0200, Michael Olbrich wrote:
> On Wed, Apr 12, 2017 at 10:27:30AM +0200, Enrico Weigelt, metux IT consult wrote:
> > On 11.04.2017 12:07, Michael Olbrich wrote:
> > > I've just pushed a large series of commits for /usr merge. This means that
> > > /bin, /sbin and /lib are now symlinks to the corresponding directories in
> > > /usr. All files are installed accordingly.
> > 
> > Just curious: what's the actual problem to solve ?
> 
> The issues below.
> 
> > For my embedded projects, I haven't had an actual usecase for having
> > them separated, but on server systems lots of them over the past 20yrs.
> > 
> > Note that this separation indeed has serious reaons: separating the
> > base system (IOW: everything required to boot up at least to single
> > user mode and mount /usr - whereever it might come from). Most of the
> > practical usecases might be obsolete now (eg. storage is so cheap that
> > people rarely have the need to share /usr within clusters, etc), but
> > still there're lots of systems out there relying on that (maybe quite
> > irrelevant to ptxdist, but certainly for standard like Debian)
> > 
> > I'm personally agnostic to that, but I've already seen such setups
> > (eg. having /usr on separate SDcard) in embedded systems. So, it seems
> > better if that remains configurable.

That's also seen on many consumer electronic devices, but given poor
quality (hack until it works and then it's done), I wouldn't take it
as any measure.

Btw, this is quite a nice summary:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

[snip]
> > I really have a bad feeling about such magic in existing commands,
> > which now suddenly change semantics.
> 
> That depends on your definition of changed semantics. After all, the files
> are still reachable at the specified path.
> 
> > At least that should be configurable.
> 
> Doing that is a lot of work. Because that only makes sense, if a separate
> /usr _really_ works. And that is more than making the recent changes
> optional. It starts with making sure that nothing outside /usr needs
> anything in /usr and continues with a clear concept of what should be
> possible without /usr mounted.
> I certainly don't have the time to do the initial work or maintain this
> longterm.
> 
> We have quite a few contributors that add new packages and keep packages up
> to date. But I'm the only one that actually works on the core stuff.
> So unless someone steps up to do this including the maintenance, it's not
> going to happen.

...and also does not need to happen ;-)
Anyway (and back to more constructive note), I updated and tested all my five
configurations and didn't find any issues. Nice work!

Thanks,
	ladis

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

  reply	other threads:[~2017-04-12 12:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11 10:07 Michael Olbrich
2017-04-12  8:27 ` Enrico Weigelt, metux IT consult
2017-04-12  9:24   ` Michael Olbrich
2017-04-12 12:06     ` Ladislav Michl [this message]
2017-04-12 12:36     ` Enrico Weigelt, metux IT consult
2017-04-12 13:36       ` Clemens Gruber
2017-04-12 18:42       ` Alexander Dahl

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=20170412120618.tuaikcgtxma7iap7@lenoch \
    --to=ladis@linux-mips.org \
    --cc=ptxdist@pengutronix.de \
    /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