On Mon, Sep 30, 2013 at 2:24 PM, pk <pete...@coolmail.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
