On Tue, 24 Mar 2009, Jakub Jelinek wrote:
On Tue, Mar 24, 2009 at 10:07:30AM +0200, Panu Matilainen wrote:
>> Basically, have rpm -V ignore timestamp verification on %license files.
>
> Make that "have rpm -V ignore timestamp verification on files whose
> hardlink count is > 1". That's reasonably in line with how rpm -V
> currently treats files shared among multiple packages and makes
> hardlink-on-content verification-friendly for any files, and without
> making licenses a totally oddball special case in verify.
gcc contains hardlinks (e.g. /usr/bin/{,x86_64-redhat-linux-}gcc) and for
these I'd prefer if the timestamp verification was done. Also,
if e.g. /tmp is on the same filesystem as /bin, any user can do
ln -f /bin/login /tmp/abcdefg
and avoid timestamp verification of /bin/login on subsequent rpm -V.
Hmm okay, any user being able to modivy rpm -V behavior is not exactly
good, although timestamp verify is pretty feeble business (considering rpm
doesnt raise conflicts on timestamp differences).
I just seriously dislike the idea of making license files somehow highly
special with different rules to everything else, when we're basically
talking about "files hardlinked outside of packaging".
>> Then, upon install, if there is already another %license file
present
>> with identical {md5,sha{256,512}} sum and size installed and if so, do a
>> byte by byte comparison and hardlink the files if they are indeed identical.
>>
>> I'm not sure whether that overcomplicates the transaction or not (also,
>> removal would probably need to make sure we didn't leave a package
>> without a license text).
A removal of a hardlink just decreases the link count, so as long as there
is at least once license file, it won't be erased.
> And on every upgrade check that hardlinked files are still shareable and
> if not undo hardlinks... eww. Sounds like a whole lotta trouble for very
> little gain.
I thought rpm doesn't overwrite files, but instead unpacks them under a
temporary name and renames them over. Which would mean after rename it
would be no longer a hardlink, so no need to undo hardlinks in any way.
Duh, indeed. I'm not thinking straight :)
- Panu -