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

Mon Jan 16 20:55:55 CET 2012

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).
+
+