On 12/14/2011 04:43 PM, J.A. Bezemer wrote:
Yep, that's actually the case for how I got pulled into the fray here. I recently did a squeeze install on the new laptop. I take the laptop out on the world a lot in a powered off state, and thought it would be nice to try Luks encryption for an extra layer of security, mostly for the sake of /home, /var /etc and swap. So I chose the automated partitioning scheme for encrypted LVM on the install disc. I really just wanted the encryption, and at first thought the extra LVM layer was an annoyance. Later, I found the LVM layer was cool to have because / needed much more space than d-i gave it, for backports kernels and headers (for modules for wireless card, etc.), and encrypted /usr (especially without AES acceleration on my processor) was a noticeable performance loss. So I was able to move /usr to the unencrypted partition I made after resizing LVM, expanded /, got backports kernels going (to the joy of the now working sound-card on the new machine), and now everything is working great. ... ... With the one caveat which brings us to today, that now I get complaints in the boot log when certain /bin functions are called with dependencies in /usr/lib that haven't been mounted yet. OK, so I admit it, don't shoot me, but the truth of the matter is that these boot log errors haven't yet practically caused me harm in any way (other than the time spent trying to be a responsible admin for my system and track down the reason I'm seeing log errors before they DO jump out and bite me right at the time of a crucial work deadline or whatever). On 12/14/2011 06:08 PM, Michael Biebl wrote: I acknowledge that such installations are around (especially since d-i presents this partitioning scheme in such a prominent way) Yep! In fact, one irony in this discussion is that on my own I wouldn't have dreamed of going to the effort to take the initiative to understand working with a separate /usr partition, if not for the fact that d-i had put it out in front of me! But actually, at the end of the day, it worked out well because I (and apparently others) have found that having a generally encrypted system with an unencrypted /usr is actually advantageous. And if someone does snag my laptop and want to yank out the hard drive, I'm really not concerned about them being able to find out what applications I have in my /usr. On 12/14/2011 03:43 PM, Roger Leigh wrote:
I think we're not fully understanding each other here. You are talking about "one system's essential package" vs. another system's "non-important tool". We can agree that the package priority level (important vs. standard vs. optional) is subjective, and we can agree that in many ways, in many cases, it may be a subjective call as to whether an executable belongs in /sbin vs. /usr/sbin, for example. But what I'm calling "consistency" is as follows: once you have determined the location of all the binary executables across a given repository, you then have a fixed, objective, algorithmic rule for determining the placement of all the libraries in that repository. Here is the explicit algorithm (I don't necessarily expect anyone to actually do it this way, but I'm a mathematician and we mathematicians like to write stuff like this out to either prove the existence of well-defined algorithms, or conversely to expose underlying false assumptions, so let's give it a try): Library Placement Algorithm (LPA): 1) Consider the set of all possible binary executables that any package in the given repo has chosen to put in /sbin or /bin, and put all such binaries there. (I realize this may not(?) be possible to do with a package manager, namely dpkg/apt, because of the existence of conflicting packages, but rememeber I'm making a point here with an abstract algorithmic presentation. Let's say you manually unpack all packages and put the binary executables there in /(s)bin.)Definition: We say a system satisfies the "FHS-LDD property" if the command ldd /{s,}bin | grep "=> /usr"returns nothing. Definition: We say a repo (or distro?) satisfies the "FHS-LDD property" if any system that installs a subset of the packages from that repo/distro satisfies the FHS-LDD on that system. My claim: A distro that uses the LPA satisfies the FHS-LDD property in the most efficient manner possible. That is to say, it satisfies the FHS-LDD property for that distro, and any other partitioning of libraries between /usr/lib and /lib which would satisfy the FHS-LDD property for this system would necessary place a set of libraries in /lib which was a superset of that produced by LPA. If my claim is valid, then I will have shown that there is in fact a unique, objectively "best" way for libraries to be partitioned between /usr/lib and /lib. Now, I know from professional work experience that this is the point where the more practically grounded folks jump in and kick my abstract mathematician legs out from underneath me and say, "Nice theorem buddy, but in the real world...." OK. So now to the wise folks who said, "We all have better things to be doing than this," good on you! Kudos to anyone who ignores my bug report in favor of doing something with their life that actually matters! -Zach |