Web lists-archives.com

Re: usrmerge -- plan B?

On Nov 26, Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> I could do it.  But, frankly, this is quite a lot of work.  I think
> the work (throughout the Debian ecosystem) to test this properly far
> outweighs the minor benefits.
I disagree both that simple testing (that you could do with a KVM 
snapshot as well) would be hard and I disagree that the benefits of 
merged-/usr would be minor.

> And if I do test it and find a lot of bugs then am I going to be
> expected to report them all in detail ?  That is also a ton of work.
> Am I then going to be expected to retest when the bugs are allegedly
> fixed ?  I think this is just outsourcing the pain of bad design
> choices, frankly.
I have not seen any better design proposals so far.

> If we must get to merged-usr on all systems eventually, Adam's
> proposed transition plan is much better.
His plan would not work any better, it would break compatibility with 
every third party software which uses /bin/, /sbin and /lib (and its own 
subdirectories), it would require a huge amount of work by everybody to 
modify most packages (assuming that it were feasible), and meanwhile 
take forever.
His plan would not solve any of your concerns because even if it were 
executed perfectly and quickly then the conversion program would still 
be in the same exact situation as it is now: either everything in /bin/, 
/sbin and /lib (and its own subdirectories) was created by the packaging 
system, and then we already know that it can be converted automatically, 
or it was not, and then we know that there are a few cases when the 
local administrator has to decide what to do about things that were 
installed by himself in the past in the wrong place.
So, how can you seriously propose it as an option?


Attachment: signature.asc
Description: PGP signature