[Sugar-devel] Full Licence field

[Panu Matilainen]

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 -