[opensuse-packaging] rpmlint rules for /var/run
I am trying to get xrootd updated to work with systemd (as well as various other improvements), but I am running into two rules in rpmlint and I can't figure out how to make both checks pass. The problem is that it is expecting a directory in /var/run, and if I leave it off I get this warning: xrootd-server.i586: W: tmpfile-not-in-filelist /var/run/xrootd please add the specified file to your %files section as %ghost so users can easily query who created the file, it gets uninstalled on package removal and finally other rpmlint checks see it However, if I add it like this: %ghost %{_var}/run/%{name} Or this: %ghost %dir %{_var}/run/%{name} I get the following error: xrootd-server.x86_64: E: dir-or-file-in-var-run (Badness: 10000) /var/run/xrootd A file in the package is located in /var/run. It's not permitted for packages to install files in this directory. How can I set things up to satisfy both rules? The package is here: https://build.opensuse.org/package/show/home:TheBlackCat:branches:science/xr... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le vendredi 07 décembre 2018 à 13:50 -0500, Todd Rme a écrit :
I am trying to get xrootd updated to work with systemd (as well as various other improvements), but I am running into two rules in rpmlint and I can't figure out how to make both checks pass.
The problem is that it is expecting a directory in /var/run, and if I leave it off I get this warning:
xrootd-server.i586: W: tmpfile-not-in-filelist /var/run/xrootd please add the specified file to your %files section as %ghost so users can easily query who created the file, it gets uninstalled on package removal and finally other rpmlint checks see it
However, if I add it like this:
%ghost %{_var}/run/%{name}
Or this:
%ghost %dir %{_var}/run/%{name}
I get the following error:
xrootd-server.x86_64: E: dir-or-file-in-var-run (Badness: 10000) /var/run/xrootd A file in the package is located in /var/run. It's not permitted for packages to install files in this directory.
How can I set things up to satisfy both rules?
First, /var/run is obsolete, you should use /run instead (/var/run is a symlink to /run ). To create the directory, you should have tmpfiles in your package to create it at install time and for each reboot. Everything should be explained in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines (Creating files and subdirectories in /var/run and /run section). -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Dec 10, Frederic Crozat wrote:
Le vendredi 07 décembre 2018 à 13:50 -0500, Todd Rme a écrit :
I am trying to get xrootd updated to work with systemd (as well as various other improvements), but I am running into two rules in rpmlint and I can't figure out how to make both checks pass.
The problem is that it is expecting a directory in /var/run, and if I leave it off I get this warning:
xrootd-server.i586: W: tmpfile-not-in-filelist /var/run/xrootd please add the specified file to your %files section as %ghost so users can easily query who created the file, it gets uninstalled on package removal and finally other rpmlint checks see it
However, if I add it like this:
%ghost %{_var}/run/%{name}
Or this:
%ghost %dir %{_var}/run/%{name}
I get the following error:
xrootd-server.x86_64: E: dir-or-file-in-var-run (Badness: 10000) /var/run/xrootd A file in the package is located in /var/run. It's not permitted for packages to install files in this directory.
How can I set things up to satisfy both rules?
First, /var/run is obsolete, you should use /run instead (/var/run is a symlink to /run ).
To create the directory, you should have tmpfiles in your package to create it at install time and for each reboot.
Everything should be explained in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines (Creating files and subdirectories in /var/run and /run section).
Except that rpmlint needs to get fixed to check /run, too. %ghost in /run should also be forbidden like in /var/run. In general, %ghost for tmpfiles on tmpfs doesn't make any sense and only makes later a lot of trouble. This should be completly forbidden. And robustness is here more important than the wish of some people, to track every file with rpm -qf. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Thorsten Kukuk schrieb:
[...] In general, %ghost for tmpfiles on tmpfs doesn't make any sense and only makes later a lot of trouble. This should be completly
For example?
forbidden. And robustness is here more important than the wish of
Well, if robustness is the main argument then a method that requires packagers to maintain file information in two places and to add fragile scripting sections hardly reaches that goal. Scriptlets need to become the exception, not the rule. rpm needs to be enhanced to handle at least the simple cases, no need for extra configs and scripting sections. $ rpm -qvl tuned|grep run drwxr-xr-x 2 root root 0 May 14 2018 /run/tuned $ cat /usr/lib/tmpfiles.d/tuned.conf # tuned runtime directory d /run/tuned 0755 root root - cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Dec 10, Ludwig Nussel wrote:
Thorsten Kukuk schrieb:
[...] In general, %ghost for tmpfiles on tmpfs doesn't make any sense and only makes later a lot of trouble. This should be completly
For example?
Ever tried to replace a %ghost entry with a real file?
forbidden. And robustness is here more important than the wish of
Well, if robustness is the main argument then a method that requires packagers to maintain file information in two places and to add fragile scripting sections hardly reaches that goal.
Ok, with your tmpfiles/%ghost approach, we have this method, which requires packages to maintain file information in two places. So, I agree with you that we should not maintain it in two places, so drop the %ghost entries and only use tmpfiles for /run. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Thorsten Kukuk schrieb:
On Mon, Dec 10, Ludwig Nussel wrote:
Thorsten Kukuk schrieb:
[...] In general, %ghost for tmpfiles on tmpfs doesn't make any sense and only makes later a lot of trouble. This should be completly
For example?
Ever tried to replace a %ghost entry with a real file?
Can you give an example of the use case you see breaking?
forbidden. And robustness is here more important than the wish of
Well, if robustness is the main argument then a method that requires packagers to maintain file information in two places and to add fragile scripting sections hardly reaches that goal.
Ok, with your tmpfiles/%ghost approach, we have this method, which requires packages to maintain file information in two places.
As long as a spec file contains a %files section, that is the canonical place for file information and won't go away. tmpfiles config means a second place. That is independent of potential duplication of information. Anyways, back to the part you decided not to quote. It's already possible to query binary rpms for their config files, documentation, licenses etc. So it doesn't look absurd to expect information about locations where a package dumps runtime data in rpm as well. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Dec 10, 2018 at 7:40 AM Ludwig Nussel
Thorsten Kukuk schrieb:
[...] In general, %ghost for tmpfiles on tmpfs doesn't make any sense and only makes later a lot of trouble. This should be completly
For example?
forbidden. And robustness is here more important than the wish of
Well, if robustness is the main argument then a method that requires packagers to maintain file information in two places and to add fragile scripting sections hardly reaches that goal. Scriptlets need to become the exception, not the rule. rpm needs to be enhanced to handle at least the simple cases, no need for extra configs and scripting sections.
Most of these issues are self-inflicted in openSUSE. I upstreamed file triggers and macros to systemd upstream that resolved this problem earlier in the year. And prior to that, both Fedora and Mageia had implementations that allowed this to not be the case. To be quite honest, the openSUSE scriptlets for services are insane and need to be culled for the good of humanity. The fact that they are so different from everyone else when the things they are handling are otherwise exactly the same implies no one is seriously looking at what they do and how to simplify them. I would have already taken a look at doing so, if it weren't for the fact that openSUSE systemd is a fork that regularly runs behind upstream. It's depressing to see that SUSE engineers aren't contributing their changes to systemd upstream so that they don't need to maintain such heavy forks. This problem also exists with dracut, which is so far behind upstream that it's missing major features that even kiwi can't use on openSUSE, but can on every other distribution. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 2018-12-11 02:38, Neal Gompa wrote:
I would have already taken a look at doing so, if it weren't for the fact that openSUSE systemd is a fork that regularly runs behind upstream. It's depressing to see that SUSE engineers aren't contributing their changes to systemd upstream so that they don't need to maintain such heavy forks. This problem also exists with dracut,
it's "because of SLE". When you try to submit an update to Base:System/systemd, the answer is potentially "yeah ... but we'd want to share it between SLE...". Surely you can tell a maintenance tale about RHEL's systemd/dracut/etc. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Jan Engelhardt schrieb:
On Tuesday 2018-12-11 02:38, Neal Gompa wrote:
I would have already taken a look at doing so, if it weren't for the fact that openSUSE systemd is a fork that regularly runs behind upstream. It's depressing to see that SUSE engineers aren't contributing their changes to systemd upstream so that they don't need to maintain such heavy forks. This problem also exists with dracut,
it's "because of SLE". When you try to submit an update to Base:System/systemd, the answer is potentially "yeah ... but we'd want to share it between SLE...". Surely you can tell a maintenance
There are times when that argument makes more sense and there are times when it makes less. Right now I'd expect Factory to follow upstream closely with both projects. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 2018-12-11 11:36, Ludwig Nussel wrote:
Jan Engelhardt schrieb:
On Tuesday 2018-12-11 02:38, Neal Gompa wrote:
I would have already taken a look at doing so, if it weren't for the fact that openSUSE systemd is a fork that regularly runs behind upstream. It's depressing to see that SUSE engineers aren't contributing their changes to systemd upstream so that they don't need to maintain such heavy forks. This problem also exists with dracut,
it's "because of SLE". When you try to submit an update to Base:System/systemd, the answer is potentially "yeah ... but we'd want to share it between SLE...". Surely you can tell a maintenance
There are times when that argument makes more sense and there are times when it makes less. Right now I'd expect Factory to follow upstream closely with both projects.
system: 239+suse138 (some 120 loose patches tied up in a git repo as commits) vs. upstream 240. Close enough. dracut: v44 (release date 2015-Nov) + 200 loose patches vs. upstream 49. A bit far from "closely". -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Dec 11, 2018 at 5:53 AM Jan Engelhardt
On Tuesday 2018-12-11 11:36, Ludwig Nussel wrote:
Jan Engelhardt schrieb:
On Tuesday 2018-12-11 02:38, Neal Gompa wrote:
I would have already taken a look at doing so, if it weren't for the fact that openSUSE systemd is a fork that regularly runs behind upstream. It's depressing to see that SUSE engineers aren't contributing their changes to systemd upstream so that they don't need to maintain such heavy forks. This problem also exists with dracut,
it's "because of SLE". When you try to submit an update to Base:System/systemd, the answer is potentially "yeah ... but we'd want to share it between SLE...". Surely you can tell a maintenance
There are times when that argument makes more sense and there are times when it makes less. Right now I'd expect Factory to follow upstream closely with both projects.
system: 239+suse138 (some 120 loose patches tied up in a git repo as commits) vs. upstream 240. Close enough.
So there was a rebase recently. Last I looked it wasn't systemd 239.
dracut: v44 (release date 2015-Nov) + 200 loose patches vs. upstream 49. A bit far from "closely".
Yep. The other issue is that both of them have a large chunk of non-upstreamed changes (which seems to be depressingly par for the course here), which makes it *really hard* for openSUSE to track upstream releases. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Dec 10, 2018 at 9:02 PM Jan Engelhardt
On Tuesday 2018-12-11 02:38, Neal Gompa wrote:
I would have already taken a look at doing so, if it weren't for the fact that openSUSE systemd is a fork that regularly runs behind upstream. It's depressing to see that SUSE engineers aren't contributing their changes to systemd upstream so that they don't need to maintain such heavy forks. This problem also exists with dracut,
it's "because of SLE". When you try to submit an update to Base:System/systemd, the answer is potentially "yeah ... but we'd want to share it between SLE...". Surely you can tell a maintenance tale about RHEL's systemd/dracut/etc.
Actually, in Fedora, we track upstream. RHEL is downstream of Fedora, so it's usually not my problem. Moreover, they often cherrypick fixes from Fedora rather than the other way around. This is what's broken here in openSUSE. Despite having this rolling model for Tumbleweed and Factory, stuff in the base gets updated *less* often than before. And now SLE is used as an excuse when it shouldn't be. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Dec 10, 2018 at 4:47 AM Thorsten Kukuk
On Mon, Dec 10, Frederic Crozat wrote:
Le vendredi 07 décembre 2018 à 13:50 -0500, Todd Rme a écrit :
I am trying to get xrootd updated to work with systemd (as well as various other improvements), but I am running into two rules in rpmlint and I can't figure out how to make both checks pass.
The problem is that it is expecting a directory in /var/run, and if I leave it off I get this warning:
xrootd-server.i586: W: tmpfile-not-in-filelist /var/run/xrootd please add the specified file to your %files section as %ghost so users can easily query who created the file, it gets uninstalled on package removal and finally other rpmlint checks see it
However, if I add it like this:
%ghost %{_var}/run/%{name}
Or this:
%ghost %dir %{_var}/run/%{name}
I get the following error:
xrootd-server.x86_64: E: dir-or-file-in-var-run (Badness: 10000) /var/run/xrootd A file in the package is located in /var/run. It's not permitted for packages to install files in this directory.
How can I set things up to satisfy both rules?
First, /var/run is obsolete, you should use /run instead (/var/run is a symlink to /run ).
To create the directory, you should have tmpfiles in your package to create it at install time and for each reboot.
Everything should be explained in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines (Creating files and subdirectories in /var/run and /run section).
Except that rpmlint needs to get fixed to check /run, too. %ghost in /run should also be forbidden like in /var/run.
In general, %ghost for tmpfiles on tmpfs doesn't make any sense and only makes later a lot of trouble. This should be completly forbidden. And robustness is here more important than the wish of some people, to track every file with rpm -qf.
Thorsten
Then can we get rid of the rpmlint message saying %ghost is required in /var/run? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (6)
-
Frederic Crozat -
Jan Engelhardt -
Ludwig Nussel -
Neal Gompa -
Thorsten Kukuk -
Todd Rme