[Mageia-dev] Over-zealous rpmlint policy (rejecting rt)

[David Walser]

Michael Scherer wrote:
> Le jeudi 12 janvier 2012 à 11:12 +0200, Buchan Milne a écrit :
>> I am trying to get rt (3.8.11) into the distro (a package that I am using on a 
>> different distro in a production environment), to be followed up with the rt 
>> (4.0.4) I have queued (which I am testing in preparation for upgrading our 
>> production environment).
>> 
>> I would really like to get this package into the distro, but it is being 
>> rejected 
>> (http://pkgsubmit.mageia.org/uploads/rejected//cauldron/core/release/20120110140334.buchan.valstar.18287.youri) 
>> due to:
>> 
>> Submission errors, aborting:
>> - rt-3.8.11-1.mga2.noarch:
>>  - dir-or-file-in-usr-local /usr/local/lib/rt/plugins
>>  - dir-or-file-in-usr-local /usr/local/lib/rt
>>  - dir-or-file-in-usr-local /usr/local/lib/rt/po
>>  - dir-or-file-in-usr-local /usr/local/lib/rt/lib
>>  - dir-or-file-in-usr-local /usr/local/etc/rt
>>  - dir-or-file-in-usr-local /usr/local/lib/rt/html
>> 
>> The documented way for extending RT is by installing files in this location. 
>> We can either:
>> 1)Make it more difficult for users to extend RT with local plugins etc.
>> 2)Fix rpmlint
>> 3)Not have RT
>> 
>> misc, you have experience of both rt and rpmlint, can you provide an opinion?
>>
>> Would it be possible to separate 'dir-or-file-usr-local' into separate rules 
>> (one for files, one for dirs)? While I agree we shouldn't ship files in 
>> /usr/local, I don't see why we shouldn't ship dirs in /usr/local ...
> 
> We shouldn't ship directories for the same reason that we shouldn't ship
> file, ie FHS.
> 
> See :
> http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLOCALLOCALHIERARCHY
> 
> More specifically :
> "It needs to be safe from being overwritten when the system software is
> updated."
> 
> So the question is whether someone who change directory permissions will
> see them overwritten or not when the software is updated, and wether
> that a FHS violation.
> 
> Afaik, rpm would reset the permission ( the same goes for removal of the
> directory ). 
> 
> See also :
> "No other directories, except those listed below, may be in /usr/local
> after first installing a FHS-compliant system."
> 
> Again, that's not clear if we can modify it later or not ( ie, is
> instaling rt on installation part of "first installing" or not ).
> 
> I guess we should get a opinion from FHS/LSB people on this.
> 
> In the mean time, I guess the point 1 is the easiest way, it can be
> changed later once we clarified FHS (or if we decide that we do not care
> about following standards, but that's really something I would like to
> avoid ). 

Not to mention there may be installations where /usr/local is NFS shared across a network and having the package manager trying to write 
there could cause problems.  Maybe another possible solution is to have the software create the needed directory at some point, but don't 
have the package itself create or own it.  CUPS is already doing this with /usr/local/lib/printdriver and /usr/local/share/ppd (and 
equivalents in /opt).