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 -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
