On 2011-03-02, at 10:45, Oliver Tappe wrote: > On 2011-03-02 at 00:04, Truls Becken wrote: > >> In a thread back in january [1], I made a suggestion about letting >> /boot/system and /boot/common be both the package-fs mount point and >> at the same time hold a couple of "real" directories (packages, >> settings). I don't know if anybody noticed and considered it as an >> option back then, but it might solve some problems. >> >> As far as I can see, it has these (dis)advantages: >> >> + Good for backward compatibility >> + Short (sane) paths to e.g. /boot/system/apps >> + No need for B_SYSTEM_PACKAGES_CONTENTS >> - Confusing to have package contents mangled with actual folders >> - Can't use both package based and manually organized files, as in [2] > > Yep, we could solve the latter by explicitly providing an 'old-school' or > 'legacy' folder (or whatever else would be a good name for it). That could > both be used for testing software during development and for installing > software that isn't available as hpkg. Yes, this basically means switching the primary (/boot/common) and secondary (/boot/common/something) folders. Instead of /boot/common/packages/contents you have /boot/common/legacy as secondary. This is a good thing for /boot/system since the legacy part would not exist there. You get the same need for a legacy folder with the symlinks Ingo mentioned, btw. I should add another disadvantage to the list, though: The set of "real" folders needs to be decided up front since they are effectively banned for use in packages. Or you could say that there is a list of folders that are ok in packages, and any others are not guaranteed to work. -Truls