Re: [Mageia-dev] Over-zealous rpmlint policy (rejecting rt)
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).
[Mageia-dev] Over-zealous rpmlint policy (rejecting rt)
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 ... Regards, Buchan
Re: [Mageia-dev] Over-zealous rpmlint policy (rejecting rt)
'Twas brillig, and Buchan Milne at 12/01/12 09:12 did gyre and gimble: I don't see why we shouldn't ship dirs in /usr/local ... I don't really see the point in shipping the dirs personally. Any separate extension that is packaged should not go into /usr/local anyway, so these folders are purely for users doing this manually. I would expect that the make install stage of any extension installation would automatically create those folders anyway, so I really don't see the benefit of adding these empty folders into a package. The gain in doing so seems minimal to the point of useless. Of course if extensions do not have installer scripts then the user will have to create those folders themselves, but if they are following a manual recipe anyway, what's an extra mkdir during that process going to cost them? Very little IMO. Disclaimer: I have no experience of rt itself, so I could be missing something contextual here. Cheers! Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Over-zealous rpmlint policy (rejecting rt)
On Thursday, 12 January 2012 11:55:07 Colin Guthrie wrote: 'Twas brillig, and Buchan Milne at 12/01/12 09:12 did gyre and gimble: I don't see why we shouldn't ship dirs in /usr/local ... I don't really see the point in shipping the dirs personally. Any separate extension that is packaged should not go into /usr/local anyway, No one ever said they would, you snipped the part of my mail saying that 'locally installed' customisations, IOW, ones not managed by the package manager etc., go there. so these folders are purely for users doing this manually. Yes. And that's why we provide /usr/local/share/applications? /me wonders if 'filesystem' would make it through the BS. I would expect that the make install stage of any extension installation would automatically create those folders anyway, so I really don't see the benefit of adding these empty folders into a package. So, why would 'make isntall' of rt, which has been configured to itself live in a system location, explicitly create these directories? The gain in doing so seems minimal to the point of useless. I can remove the dirs in the package, but also, what is the benefit? On a system dedicated to running a request tracking system, should we explicitly make it more difficult to run said system that it would be if installed from source? Of course if extensions do not have installer scripts then the user will have to create those folders themselves, but if they are following a manual recipe anyway, what's an extra mkdir during that process going to cost them? Very little IMO. Disclaimer: I have no experience of rt itself, so I could be missing something contextual here. Well, I haven't myself used extensions that live here, because I have to be careful not to deliver something one of our vendors is contracted to deliver. I'll test one on my laptop ... Regards, Buchan
Re: [Mageia-dev] Over-zealous rpmlint policy (rejecting rt)
'Twas brillig, and Buchan Milne at 12/01/12 11:39 did gyre and gimble: On Thursday, 12 January 2012 11:55:07 Colin Guthrie wrote: 'Twas brillig, and Buchan Milne at 12/01/12 09:12 did gyre and gimble: I don't see why we shouldn't ship dirs in /usr/local ... I don't really see the point in shipping the dirs personally. Any separate extension that is packaged should not go into /usr/local anyway, No one ever said they would, you snipped the part of my mail saying that 'locally installed' customisations, IOW, ones not managed by the package manager etc., go there. Yeah I know I was just trying to be explicit and clear with my reply and reasoning. I wasn't pointing out something you missed or anything. Sorry for the confusion (the opposite of what I had intended!) so these folders are purely for users doing this manually. Yes. And that's why we provide /usr/local/share/applications? Hmm, that seems a bit silly to me. Why do we provide that? I'd say we should drop it unless someone can argue otherwise (maybe it's part of the filesystem layout spec?) I would expect that the make install stage of any extension installation would automatically create those folders anyway, so I really don't see the benefit of adding these empty folders into a package. So, why would 'make isntall' of rt, which has been configured to itself live in a system location, explicitly create these directories? Because it's broken? Just because the upstream folks do something like that does not mean they are correct. I'd say that if any app's make install is writing things outside of their --prefix (with a few exceptions for things like udev rules etc. that need to live in /lib - but thankfully with the work done by Fedora folks even this exception is dying away) or --sysconfdir etc. then it's broken. The gain in doing so seems minimal to the point of useless. I can remove the dirs in the package, but also, what is the benefit? On a system dedicated to running a request tracking system, should we explicitly make it more difficult to run said system that it would be if installed from source? I really don't buy the make it more difficult argument... that's what I was trying to highlight in my previous mail. The make install stage of any extension should make the dirs for you anyway... If that's the case it is precisely the same difficulty as without those dirs. If manual copying is required, then, yes, it is a tiny amount more complicated, but people will be following instructions anyway and if the added complication of a mkdir command or two will trip someone up, then I don't think that person should have root powers and able to write in /usr/local in the first place if this is their level of skill!!! Like I say, this is just my opinion, and I certainly don't feel super strongly on the topic. It's just that I wouldn't expect any rpm to own anything in /usr/local tree (and that goes for the one you pointed out above too!). Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Over-zealous rpmlint policy (rejecting rt)
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 ). -- Michael Scherer
