mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] /usr merge
Date: Wed, 12 Apr 2017 11:24:35 +0200	[thread overview]
Message-ID: <20170412092435.6co6bltno2e7qzzr@pengutronix.de> (raw)
In-Reply-To: <e1e8f89b-b08c-8fd8-0c3f-8f14e4ad099c@gr13.net>

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.

I haven't seen any done with PTXdist. And while I don't know the exact
use-case, I think starting with an initrd and then switching to the rootfs
on the SDcard make more sense.

A separate /usr requires a lot of work. I'm quite certain, that we had
several programs in /bin and /sbin that linked to libraries in /usr and
nobody ever complained about it here.

> > I'm not going to rehash all the arguments for this. My main motivations
> > are:
> > - It's where the big distros are going, so it's better tested in the long
> >   term.
> 
> Note that this already caused a lot of trouble there. (eg. there've
> been huge flamewars @debian). IIRC that all started w/ the systemd
> mess, which suddenly introduced hard dependencies to things in /usr -
> the reaction of Lennart+friends was just ranting aaginst who relies
> on the separation.

Yes, flamewars and rants in all directions. Are there any real discussions
to solve the problems? After all, a separate /usr is one solution to a set
of problems, but why should it be the only solution?

> > - We've had several problems in the past where programs where searched in
> >   the wrong location. And busybox didn't make that any easier.
> 
> Correct me if I'm wrong, but isn't that what $PATH is for ?

No. $PATH only really works in a shell. exec*() requires the full path to
the executable and those are built into the binaries. These paths may be
hard coded in the source, or maybe detected with AC_PATH_PROG. That's
especially tricky because, unless the correct environment variable is set,
the path from the build host is used and it may work on one distro but not
the other. And then there is busybox with its own idea where the programs
should be. If that differs from the corresponding 'real' program, then
there isn't even a "correct" path to use.
And this has happened before and it's really hard to get this right.

> > How it works in PTXdist:
> > - install_copy and friends will transparently move files to /usr where
> >   appropriate. So if you have packages that install files to /bin etc. it
> >   should just work. If not, please sent a mail to this list.
> 
> 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.

Regards,
Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

  reply	other threads:[~2017-04-12  9:24 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 [this message]
2017-04-12 12:06     ` Ladislav Michl
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=20170412092435.6co6bltno2e7qzzr@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --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