Re: [ptxdist] /usr merge

["Enrico Weigelt, metux IT consult" <enrico.weigelt@gr13.net>]

On 12.04.2017 11:24, Michael Olbrich wrote:

Hi,

> I haven't seen any done with PTXdist. 

I did, quite some years ago, no idea whether it still exists.

> 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.

Sure, that would be an option (and what several large distros do),
and for new systems I'd choose either that approach, or even having
an entirely separate rescue system.

My concern is that there might be lots of systems in the field, that
can't be easily migrated. So, there it should be configurable, at least
for some time.

Anyways, I wonder why the merge hasn't been done exactly the opposite
way and perhaps symlinking /usr/bin to /bin, etc.

> Yes, flamewars and rants in all directions. Are there any real discussions
> to solve the problems? 

I'd always start w/ asking what the real problem to solve actually is.
Unfortunately, in our branch seems to have the tendency to provide
lots of solutions for unknown problems ;-)

> After all, a separate /usr is one solution to a set
> of problems, but why should it be the only solution?

Sure. But we could ask the same question for any other solution.
My point here is that having separate /usr has a long tradition (even
longer than Linux itself exists), so we should be quite cautious w/
dropping that, w/o giving a proper fallback.

By the way: in Linux embedded world, we also have people splitting
up between OS and their own applications, leading to the interesting
questions, where the border line actually is (on which side do eg.
libxml or boost belong ?). I'd rather like not to open that can of
worms, but IMHO it seems to root back to the same fundamental problem.

>> 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. 

Okay, forgot that, as I'm usually not hardcoding any exec pathes
(or even use system()+friends, if applicable).

> These paths may be hard coded in the source, or maybe detected with AC_PATH_PROG.

Hardcoded in the source seems a really, really bad idea.
OTOH, is AC_PATH_PROG even cross/sysroot-aware ?

I just dont remember any case where some package expects a program in
/usr/bin, which traditionally is in /bin. But there're cases in the
opposite direction, eg. the recent busybox-tar issue here on the list.

> 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.

Looks like all the problems we had w/ autotools (and autotool'ed
packages) in the last decades, simply working on false assumptions,
just like AC_TRY_RUN() and friends. Merging /usr doesn't solve the
underlying problem - it just reduces the set of actual breaks for a
little bit.

The fundamentally wrong assumption is that build and target system
have anything to do w/ each other (and things like crosscompiling
were just be some weird corner cases) - that also hits standard
distros like Debian (IIRC, they still run most of the cross builds
in qemu).

> 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.

So, could busybox just be wrong, and it should be fixed there ?
Why not letting busybox install the corresponding programs
(actually, symlinks) into the standard places ?

Merging /usr for that reason reminds me to the old Cinderella
story ... :o

"There they go, there they go!
There is blood on her shoe;
The shoe is too small,
Not the right bride at all!"

> That depends on your definition of changed semantics. After all,
> the files are still reachable at the specified path.

The change is that they aren't in /bin + friends anymore, just
symlinks to the actual programs somwhere under /usr.

If we're already breaking FHS, we could also do it in the exactly
opposive direction - moving /usr/bin/* to /bin/, etc. Or symlink
the whole directories (instead of individual files). Or put each
package into it's own prefix and use unions put everything together,
like Plan9 does.

I wonder when anybody proposes drive letters ...
(we already have the registry, so that doesn't seem to unlikely :o)

> 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.

Once upon a time, it had been so. (it's just a few years ago since
distros start breaking that, eg. makeing desktop tools part of the
early boot process)

> I certainly don't have the time to do the initial work or maintain this
> longterm.

I don't remeber anybody asking you to do that. No idea how many people
are around here, but I'm sure we've got enough manpower here to
distribute the load onto many shoulders and solve the problem at the
root, once and for all. Add me to the list of volounteers. (my time is
limited, too, but I believe it's an area worth solving once and for
all, instead of adding one workaround atop another)


--mtx


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de