Fedora 17’s unified filesystem (/usr-move)

[Panu Matilainen]

On 02/01/2012 06:38 PM, Bill Nottingham wrote:
> Panu Matilainen (pmatilai at laiskiainen.org) said:
>>>>> To-be-installed files obviously have no on-disk fingerprints, so it
>>>>> wont work for initial installation. So yes, those "fake" compatibility
>>>>> provides are needed. Strictly speaking, compatibility provides would
>>>>> be needed for ALL the moved files, not just /bin, as it's technically
>>>>> perfectly legal for a package to depend on an arbitrary path in
>>>>> /lib[64], not just /[s]bin.
>>>>>
>>>>>     - Panu -
>>>>
>>>> Would it be possible to leave out these provides and fix each individual
>>>> package to require in the new path instead?
>>>
>>> It isn't practical to "fix" every package that requires /bin/sh.
>>
>> It's not "just" that the impracticality either - not providing
>> /bin/sh, /sbin/ldconfig and the like would mean a huge
>> incompatibility break with nearly every existing package in the
>> wild. Not really an option.
>
> I'm not convinced of the "all" case, though. /bin/sh, /sbin/ldconfig,
> etc. could be reasonable for a package to require, and should be provided.
>
> Requires: /lib/modules/3.1.2-1.fc16/kernel/drivers/net/3c59x.ko is likely
> too dumb to live, though.

Oh, sure. Hence the "strictly speaking".

I'm not arguing for adding provides for eg /lib/modules (although I 
think I've seen such dependencies in the wonderful world of kernel 
module packaging ;), just pointing out that it's not 100% transparent 
change for package(r)s. Made ever more fun by the rpm behavior on 
installed files where you test a package on your machine, see it 
installs fine and then scratch head when it fails to work as part of 
initial install.

	- Panu -