Re: [gentoo-user] systemd installation location

[Mark David Dumlao]

On Mon, Sep 30, 2013 at 2:24 PM, pk <peterk2@××××××××.se> wrote:
> On 2013-09-30 04:05, Mark David Dumlao wrote:
>> 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.

That is not true. Even in source-based distros like gentoo, distro packagers
decide where the files go. So far, it's only in a completely from scratch *nix
environment where the end user gets to decide where files go.

And "where do the files go" is pretty much what made this problem be apparent.
Many packages with udev rules depend on programs, resources, libraries in /usr.
It is _not_ trivial to fix those packages. If _you_ think it is, I recommend you
replace the entire gentoo bugzilla community because you are clearly a
rockstar bugfixer.

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

You do not really understand the scope of the problem.

The problem is that "boot critical" is subjective to the system. A program that
is "boot critical" for one system may not be "boot critical" for another. But
where software gets installed is generally "hard coded" into packages
(defaulting to /usr). That is the status quo.

Because of this, the package manager simply does not have enough
information on whether a package is boot critical or not. It is not part of
the ebuild. It is not part of the emerge switches. Not only that, whether a
package is boot critical or not could change at any time. nfs-utils are only
boot critical if you use nfs. ssh is only boot critical if you use sshfs.
Perl is only boot critical if you have a startup script that counts the number
of virgins you've sacrificed to the goat god. Making a filesystem boot-critical
is something that the package manager does not and cannot track. Autotools
also cannot track it as it happens outside of compile time.

If you want the / and /usr separation nonsense solved, you should write a
program that can "mark" a binary as boot-critical. It will then copy the binary
and all of its libraries to /, and copy and rebuild any dependencies into / as
well. It must be a full copy, otherwise the promise that /usr can be shared
will be violated. Everytime that package is rebuilt, it must be built and copied
into _both_ / and /usr. Your program should also be able to unmark a binary
as boot critical and thus delete any copies in /

Your program should be understood by portage, or at least run as a portage
hook. Copy paste that to all package managers as well.

What's more, any program depending on a boot critical program must be
rewritten so that it looks for the program in the correct path. For backwards
compatibility, a "boot critical" program should generate\ symlinks in the
/ filesystem's /usr tree (the normally empty directory shadowed by the /usr
filesystem), so that if the /usr filesystem is not available any programs
depending on that program would still work.

That program is writable in theory. It's VERY tedious to write it, much less
test that it works.
-- 
This email is:    [ ] actionable   [x] fyi        [ ] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none