[Rpm-maint] Fedora 17’s unified filesystem (/usr-move)

[Panu Matilainen]

On 01/31/2012 11:30 PM, James Antill wrote:
> On Tue, 2012-01-31 at 15:58 -0500, Bill Nottingham wrote:
>> James Antill (james at fedoraproject.org) said:
>>>> [root at nostromo ~]# mv /bin /cow
>>>> [root at nostromo ~]# /cow/ln -s /cow /bin
>>>> [root at nostromo ~]# rpm -qf /cow/bash
>>>> bash-4.2.20-1.fc16.x86_64
>>>> [root at nostromo ~]# rpm -qf /bin/bash
>>>> bash-4.2.20-1.fc16.x86_64
>>>>
>>>> rpm should already handle this, no need for the provides.
>>>
>>>   Good to see everyone still doesn't read what I write.
>>>
>>>   As I said, rpm _does something_ to make the above work for -qf (the
>>> above even works if you inside /cow ... as long as the /bin symlink
>>> exists!).
>>>   However, it _does not_ work, if you put the above in package
>>> provides/requires and try to install them. Eg.
>>
>> It does, in some cases. Which makes it even more fun.
>>
>> Take a system with /usr/bin/sdiff.
>>
>> ...
>> Name: cow
>> Summary: cow
>> Version: 1.0
>> Release: 1
>> URL: http://redhat.com/
>> License: Moo
>> Requires: /bin/sdiff
>> ...
>>
>> root at nostromo x86_64]# rpm -ivh cow-1.0-1.x86_64.rpm --test
>> error: Failed dependencies:
>> 	/bin/sdiff is needed by cow-1.0-1.x86_64
>> [root at nostromo x86_64]# mv /bin /cow
>> [root at nostromo x86_64]# /cow/ln /usr/bin -s /bin
>> [root at nostromo x86_64]# /cow/rpm -ivh cow-1.0-1.x86_64.rpm  --test
>> Preparing...                ########################################### [100%]
>
>   IMO this is pretty crazy, because by changing the symlink back you've
> broken the prco constraints in the DB (but everything would verify as
> "correct").

Actually verify does notice this breakage (using slightly different 
sample specimen to avoid having to muck with /bin):

[root at localhost ~]# rpm -Uvh 
/home/pmatilai/rpmbuild/RPMS/noarch/cow-1.0-1.noarch.rpm
error: Failed dependencies:
	/moo/sdiff is needed by cow-1.0-1.noarch
[root at localhost ~]# ln -s /usr/bin /moo
[root at localhost ~]# rpm -Uvh 
/home/pmatilai/rpmbuild/RPMS/noarch/cow-1.0-1.noarch.rpm
Preparing...                ########################################### 
[100%]
Updating / installing...
    1:cow                    ########################################### 
[100%]
[root at localhost ~]# rpm -V cow
[root at localhost ~]# rm -f /moo
[root at localhost ~]# rpm -V cow
Unsatisfied dependencies for cow-1.0-1.noarch:
	/moo/sdiff is needed by (installed) cow-1.0-1.noarch
[root at localhost ~]#

>   It also seems like rpm is doing a _lot_ of work it doesn't need to do
> here, but who knows ... it looks pretty magic (and I'm scared to go find
> out why/how it's doing the above :).
>
>   Cc'ing rpm maintainers for their opinion on what rpm is doing and why.

This is the somewhat infamous and magical "fingerprinting" at work, 
whether you actually wanted to know it or not :)

Roughly speaking, rpm doesn't look up installed file matches by 
comparing the entire path, it compares the "fingerprint" (basically 
inode + device combination) of all matching basenames for equality.

So what happens in the above /moo/sdiff case is that rpm looks up all 
files with 'sdiff' basename from the rpmdb (in this case returning 
/usr/bin/sdiff from diffutils), and compares the fingerprint of 
/moo/sdiff and /usr/bin/sdiff for equality. When the /moo -> /usr/bin 
link is in place, /moo/sdiff and /usr/bin/sdiff are the same physical 
file regardless of the actual path used to reach it, and thus considered 
a match.

As for the why-part: its a caching and tracking mechanism for dealing 
with directories vs symlinks to directories. Whether the issue discussed 
here should be considered a side-effect or an intentional feature is 
perhaps another question, but that's how rpm has worked since very very 
early days.

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 -