[opensuse-factory] rc* symlinks and systemd
Hi, openSUSE has a packing policy of requiring rc* symlinks for each init script. So for e.g. /etc/init.d/foo there must be a symlink /usb/sbin/rcfoo -> /etc/init.d/foo. There is an rpmlint check for this policy (suse-missing-rclink). Now that more and more packages correctly switch to systemd only and drop the init scripts the rpmlint check doesn't work anymore. So we are slowly losing a nice convenience feature of openSUSE. Techically the feature works also for systemd units by making the rc symlinks point to /usr/sbin/service. When in involked as e.g. "rcfoo start" this script would then run "systemctl start foo.service". Personally I'd like to see us keeping the rc* feature also in the future so I'd like to propose introducing an rpmlint check to complain about missing rc* symlinks also for systemd unit files. Any objections on that? Otherwise I'd extend the suse-missing-rclink rpmlint check to .service files at some point. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.01.2014 13:48, schrieb Ludwig Nussel:
Personally I'd like to see us keeping the rc* feature also in the future so I'd like to propose introducing an rpmlint check to complain about missing rc* symlinks also for systemd unit files.
Any objections on that? Otherwise I'd extend the suse-missing-rclink rpmlint check to .service files at some point.
No objection but consent. The good thing is that our packaging documentation already states that symlink also for systemd units. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ludwig Nussel - 13:48 29.01.14 wrote:
Personally I'd like to see us keeping the rc* feature also in the future so I'd like to propose introducing an rpmlint check to complain about missing rc* symlinks also for systemd unit files.
Any objections on that? Otherwise I'd extend the suse-missing-rclink rpmlint check to .service files at some point.
No objection, this is really awesome feature we have and I would like to keep it around. -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/29/2014 07:48 AM, Ludwig Nussel wrote:
Hi,
openSUSE has a packing policy of requiring rc* symlinks for each init script. So for e.g. /etc/init.d/foo there must be a symlink /usb/sbin/rcfoo -> /etc/init.d/foo. There is an rpmlint check for this policy (suse-missing-rclink).
Now that more and more packages correctly switch to systemd only and drop the init scripts the rpmlint check doesn't work anymore. So we are slowly losing a nice convenience feature of openSUSE.
Techically the feature works also for systemd units by making the rc symlinks point to /usr/sbin/service. When in involked as e.g. "rcfoo start" this script would then run "systemctl start foo.service".
Personally I'd like to see us keeping the rc* feature also in the future so I'd like to propose introducing an rpmlint check to complain about missing rc* symlinks also for systemd unit files.
Any objections on that? Otherwise I'd extend the suse-missing-rclink rpmlint check to .service files at some point.
I don't care much for this "feature" but will certainly introduce the symlinks for my packages where appropriate if that's the direction we're going. While you are at it, maybe you want to create a macro that people can just use %{createRCLinks} foo bar twix And the symlinks are magically created for the packager. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Ludwig Nussel <ludwig.nussel@suse.de>:
Hi,
openSUSE has a packing policy of requiring rc* symlinks for each init script. So for e.g. /etc/init.d/foo there must be a symlink /usb/sbin/rcfoo -> /etc/init.d/foo. There is an rpmlint check for this policy (suse-missing-rclink).
A very much appreciated feature I would like to add!
Personally I'd like to see us keeping the rc* feature also in the future so I'd like to propose introducing an rpmlint check to complain about missing rc* symlinks also for systemd unit files.
Any objections on that? Otherwise I'd extend the suse-missing-rclink rpmlint check to .service files at some point.
No objection.. the sooner the better! I'd even propose a staging repo where the check does not WARN, but FAIL... so we get an overview where it's all missing. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Robert Schweikert wrote:
On 01/29/2014 07:48 AM, Ludwig Nussel wrote:
openSUSE has a packing policy of requiring rc* symlinks for each init script. So for e.g. /etc/init.d/foo there must be a symlink /usb/sbin/rcfoo -> /etc/init.d/foo. There is an rpmlint check for this policy (suse-missing-rclink). [...] I don't care much for this "feature" but will certainly introduce the symlinks for my packages where appropriate if that's the direction we're going.
While you are at it, maybe you want to create a macro that people can just use
%{createRCLinks} foo bar twix
And the symlinks are magically created for the packager.
Interesting idea. I'll keep that in mind. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Ludwig Nussel <ludwig.nussel@suse.de>:
openSUSE has a packing policy of requiring rc* symlinks for each init script. So for e.g. /etc/init.d/foo there must be a symlink /usb/sbin/rcfoo -> /etc/init.d/foo. There is an rpmlint check for this policy (suse-missing-rclink).
A very much appreciated feature I would like to add!
Personally I'd like to see us keeping the rc* feature also in the future so I'd like to propose introducing an rpmlint check to complain about missing rc* symlinks also for systemd unit files.
Any objections on that? Otherwise I'd extend the suse-missing-rclink rpmlint check to .service files at some point.
No objection.. the sooner the better! I'd even propose a staging repo where the check does not WARN, but FAIL... so we get an overview where it's all missing.
A bit extreme :-) Failing is actually not needed, one can search for the error in build logs. AFAIK there is no interface in obs that allows to fetch all build logs from a project in one request though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Ludwig Nussel <ludwig.nussel@suse.de>:
Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Ludwig Nussel <ludwig.nussel@suse.de>:
openSUSE has a packing policy of requiring rc* symlinks for each init script. So for e.g. /etc/init.d/foo there must be a symlink /usb/sbin/rcfoo -> /etc/init.d/foo. There is an rpmlint check for this policy (suse-missing-rclink).
A very much appreciated feature I would like to add!
Personally I'd like to see us keeping the rc* feature also in the future so I'd like to propose introducing an rpmlint check to complain about missing rc* symlinks also for systemd unit files.
Any objections on that? Otherwise I'd extend the suse-missing-rclink rpmlint check to .service files at some point.
No objection.. the sooner the better! I'd even propose a staging repo where the check does not WARN, but FAIL... so we get an overview where it's all missing.
A bit extreme :-) Failing is actually not needed, one can search for the error in build logs. AFAIK there is no interface in obs that allows to fetch all build logs from a project in one request though.
Yes; that's why I proposed to do the fail only in a staging project... so we get at least visibility... Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Ludwig Nussel <ludwig.nussel@suse.de>:
Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Ludwig Nussel <ludwig.nussel@suse.de>:
openSUSE has a packing policy of requiring rc* symlinks for each init script. So for e.g. /etc/init.d/foo there must be a symlink /usb/sbin/rcfoo -> /etc/init.d/foo. There is an rpmlint check for this policy (suse-missing-rclink).
A very much appreciated feature I would like to add!
Personally I'd like to see us keeping the rc* feature also in the future so I'd like to propose introducing an rpmlint check to complain about missing rc* symlinks also for systemd unit files.
Any objections on that? Otherwise I'd extend the suse-missing-rclink rpmlint check to .service files at some point.
No objection.. the sooner the better! I'd even propose a staging repo where the check does not WARN, but FAIL... so we get an overview where it's all missing.
A bit extreme :-) Failing is actually not needed, one can search for the error in build logs. AFAIK there is no interface in obs that allows to fetch all build logs from a project in one request though.
Yes; that's why I proposed to do the fail only in a staging project... so we get at least visibility...
Fine if someone volunteers to take care of that staging project :-) Personally I can't. So I would be fine with just introducing the check and look at the build logs in a few months. The following packages trigger the old check today already: kexec-tools openhpi scsirastools iprutils hp-drive-guard lsyncd irqd xsp openscap systemd php5 xdmsc istgt aaa_base glusterfs nbd cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Donnerstag, 30. Januar 2014 schrieb Ludwig Nussel:
Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Ludwig Nussel <ludwig.nussel@suse.de>:
Dominique Leuenberger a.k.a. Dimstar wrote:
A bit extreme :-) Failing is actually not needed, one can search for the error in build logs. AFAIK there is no interface in obs that allows to fetch all build logs from a project in one request though.>
Do you seriously think someone reads build logs of successful builds? ;-)
Yes; that's why I proposed to do the fail only in a staging project... so we get at least visibility...
Yes, fully agreed. I'd even go a step further and say: Either create a rc* symlink, or add a rpmlintrc explicitely stating you do not want that symlink. When all packages are updated, I'd make missing rc* symlinks (without rpmlintrc) a failure in factory, to make sure future packages also have the rc* symlink. BTW: rpmlint should also check the link target, which can be /usr/sbin/service or /etc/init.d/* (I remember at least one bug with wrong rc* symlink target)
Fine if someone volunteers to take care of that staging project :-) Personally I can't. So I would be fine with just introducing the check and look at the build logs in a few months.
Given how often I was annoyed by lost rc* symlinks, I'd say I can help with getting the rc* symlinks into the packages. However, it would be the best if the package maintainers do it because they know best if such a symlink makes sense in the specific case.
The following packages trigger the old check today already:
kexec-tools openhpi scsirastools iprutils hp-drive-guard lsyncd irqd xsp openscap systemd php5 xdmsc istgt aaa_base glusterfs nbd
I'm a bit surprised by some packages on the list - and it's funny to see systemd listed ;-) Regards, Christian Boltz --
which camera is this? Marcus, this is my bug :) [Marcus Meissner and Stephan Kulow in https://bugzilla.novell.com/show_bug.cgi?id=217731]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jan 30, 2014 at 03:31:14PM +0100, Christian Boltz wrote:
The following packages trigger the old check today already:
kexec-tools openhpi scsirastools iprutils hp-drive-guard lsyncd irqd xsp openscap systemd php5 xdmsc istgt aaa_base glusterfs nbd
I'm a bit surprised by some packages on the list - and it's funny to see systemd listed ;-)
systemd does not have any rc links which points to /etc/init.d Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
On Thu, 30 Jan 2014 10:44:00 +0100, Ludwig Nussel wrote:
The following packages trigger the old check today already: ... istgt
Thanks for the reminder Ludwig. I'll add istgt systemd to my todo list for this week. Cheers, David -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Donnerstag, 30. Januar 2014 schrieb Dr. Werner Fink:
On Thu, Jan 30, 2014 at 03:31:14PM +0100, Christian Boltz wrote:
The following packages trigger the old check today already: ... systemd ... I'm a bit surprised by some packages on the list - and it's funny to see systemd listed ;-)
systemd does not have any rc links which points to /etc/init.d
Yes, I know - but it has an initscript ;-) For those who are interested in the details: systemd-logger contains /etc/init.d/systemd-journald (which IIRC is a dummy script always printing "failed", so we better don't create a rc* symlink for it ;-) The udev package (which is part of the systemd sources) contains another initscript, /etc/init.d/boot.udev. Regards, Christian Boltz --
Mach mal Helga - Schneider - Fischer hier auf Dich aufmerksam. Die weiß alles da drüber. Schön wär's. Wenn man anfängt, das zu glauben, denkt sich KDE etwas Neues aus. Ganz bestimmt. [> Peter Lipp und Helga Fischer in suse-linux]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Thu, 30 Jan 2014 18:14:58 +0100 Christian Boltz <opensuse@cboltz.de> пишет:
The udev package (which is part of the systemd sources) contains another initscript, /etc/init.d/boot.udev.
Why would you want to manually call script which is supposed to run exactly once at system initialization? Do rc links to other boot.* scripts exist? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Donnerstag, 30. Januar 2014 schrieb Andrey Borzenkov:
Christian Boltz <opensuse@cboltz.de> пишет:
The udev package (which is part of the systemd sources) contains another initscript, /etc/init.d/boot.udev.
Why would you want to manually call script which is supposed to run exactly once at system initialization?
My mail was more a "list of initscripts in the systemd packages" - maybe I should have added "*SCNR*"
Do rc links to other boot.* scripts exist?
Yes, boot.apparmor / rcapparmor ;-) That said - I know that most /etc/init.d/boot.* scripts should run only once as boot, which also means they don't need a rc* symlink. Regards, Christian Boltz -- Wahrscheinlich habe ich wieder fürchterlichen Code produziert, aber du bist ja mittlerweile schon beinahe mein persönlicher Codestaubsauger. ;-) [Andreas Schott] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-30 22:04, Christian Boltz wrote:
Do rc links to other boot.* scripts exist?
Yes, boot.apparmor / rcapparmor ;-)
Or rccrypto, previously. It does not exist now. It is not clear to me how it would be added with systemd.
That said - I know that most /etc/init.d/boot.* scripts should run only once as boot, which also means they don't need a rc* symlink.
True. Only some exist. IIRC, the rccrypto link was added after I suggested it on some bugzilla. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLqwNcACgkQtTMYHG2NR9VXpACfVOEJRGZBnLo5xSXwPgw8Pzpz LmsAnR7Att0DAKg0McNU1a7RZNeGGLdD =5wli -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-01-30 22:04, Christian Boltz wrote:
Do rc links to other boot.* scripts exist?
Yes, boot.apparmor / rcapparmor ;-)
Or rccrypto, previously. It does not exist now. It is not clear to me how it would be added with systemd.
You could have a crypto.target that connects all cryptsetup@.service, then symlink /usr/sbin/service to rccrypto. There's already a cryptsetup.target. So maybe that target already works. Try a symlink with name rccryptsetup. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Christian Boltz wrote:
Am Donnerstag, 30. Januar 2014 schrieb Ludwig Nussel:
Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Ludwig Nussel <ludwig.nussel@suse.de>:
Dominique Leuenberger a.k.a. Dimstar wrote:
A bit extreme :-) Failing is actually not needed, one can search for the error in build logs. AFAIK there is no interface in obs that allows to fetch all build logs from a project in one request though.>
Do you seriously think someone reads build logs of successful builds? ;-)
Yes; that's why I proposed to do the fail only in a staging project... so we get at least visibility...
Yes, fully agreed.
I'd even go a step further and say: Either create a rc* symlink, or add a rpmlintrc explicitely stating you do not want that symlink.
We need to be careful with that tool. It's already annoying enough. The rc symlinks are just some sugar, it's not really crucial to have. Some page that shows the current rpmlint results of the whole Factory project would be more useful IMO. Esp if it had a way to file bugs in batch mode :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Freitag, 31. Januar 2014 schrieb Ludwig Nussel:
Christian Boltz wrote:
Am Donnerstag, 30. Januar 2014 schrieb Ludwig Nussel:
Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Ludwig Nussel <ludwig.nussel@suse.de>:
Dominique Leuenberger a.k.a. Dimstar wrote:
I'd even go a step further and say: Either create a rc* symlink, or add a rpmlintrc explicitely stating you do not want that symlink. We need to be careful with that tool. It's already annoying enough. The rc symlinks are just some sugar, it's not really crucial to have.
I know (and IIRC was also hit by rpmlint in the past once). Nevertheless, if we handle it in a staging project first, it shouldn't be too annoying ;-) Hey, we survived the "fuzzy patches aren't allowed anymore" some years ago, so we'll easily survive the "no rc* symlink" ;-)
Some page that shows the current rpmlint results of the whole Factory project would be more useful IMO. Esp if it had a way to file bugs in batch mode :-)
Do you really think batch-filed bugreports are the better solution? I doubt ;-) As a maintainer, I'd prefer to have a rpmlint message like Your package contains foo.service, but no rcfoo symlink. You can create the rcfoo symlink by adding this line to your spec: ( mkdir -p %{buildroot}/usr/sbin && cd %{buildroot}/usr/sbin && ln -s service rcfoo ) and add the symlink to %files: /usr/sbin/rcfoo If you think a rcfoo symlink doesn't make sense for your package (for example because foo.service should never be started or stopped manually), add the following line to rpmlintrc: [copy&paste-ready line for rpmlintrc] For a packager that would mean: build failure -> copy&paste from rpmlint message (to spec or rpmlintrc) -> success I wouldn't call that annyoing - especially when the error message contains clear instructions what to do. OTOH, I somehow doubt a manual bugreport (batchmode or not) will always contain that information - in other words: it's harder for the packager to handle it. Also, especially with batch mode, you'll probably get a fresh bugreport some months later because you still didn't add a rc* symlink (for whatever reason) and the batch-reporter won't check bugzilla for old reports in 30 packages ;-) That all said - yes, a page with a list of all factory rpmlint warnings would be nice to have, but I'm afraid not many people will read it. (If the average package comes with 3 rpmlint warnings, the list for all packages will be quite big ;-) Maybe we should encourage packagers to add a rpmlintrc for all known (and intentionally ignored) rpmlint warnings to make the list shorter, but that's another discussion ;-) [1] and most probably a bigger annoyance than the discussion about rcfoo symlinks. Regards, Christian Boltz [1] for the packages I maintain, I could imagine to - list all "well-known" rpmlint warnings in rpmlintrc - add a special comment "# rpmlint-all-fatal" to the spec that makes _all_ _new_ rpmlint warnings fatal. The advantage of this method would be to notice new warnings quickly [2], but I also know that it would mean lots of work to get it started. That's why I include "add a special comment to the spec to enable this behaviour" which means it's opt-in for each package(r). What do you think about this idea? [2] again: do you seriously think someone reads the build log if the build succeeds? ;-) -- Aber bei Sendmail weiss man ja nie, ist ja ne Mischung aus Programmier- sprache und halben Betriebssystem, die bei geeigneter Konfiguration wie ein MTA aussehen kann... [Steffen Dettmer in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 30/01/14 18:04, Christian Boltz escribió:
Yes, boot.apparmor / rcapparmor ;-)
Patches for native apparmor profile support in systemd has been posted but not yet merged. Unit directive is called AppArmorProfile= This is to switch profiles but not to load them, that part is still missing. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Freitag, 31. Januar 2014 schrieb Cristian Rodríguez:
El 30/01/14 18:04, Christian Boltz escribió:
Yes, boot.apparmor / rcapparmor ;-)
Patches for native apparmor profile support in systemd has been posted but not yet merged.
Unit directive is called AppArmorProfile=
This is to switch profiles but not to load them, that part is still missing.
Thanks for the pointer ;-) If someone is interested in details: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg15717.ht... Regards, Christian Boltz --
*gruebel* Beenden sich Zombie-Prozesse nicht irgendwann mal von selbst? Ne, die sind ja schon beendet. Umpf. Jetzt wird's schwierig. Wie zum Henker tötet man tote Untote, die schon gestorben sind? [Eilert Brinkmann und Martin Leidig in suse-talk]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Christian Boltz wrote:
Am Freitag, 31. Januar 2014 schrieb Ludwig Nussel: [...]
Some page that shows the current rpmlint results of the whole Factory project would be more useful IMO. Esp if it had a way to file bugs in batch mode :-)
Do you really think batch-filed bugreports are the better solution? I doubt ;-)
I think so, yes. At least it worked in the past. See e.g.: https://bugzilla.novell.com/showdependencytree.cgi?id=764093&hide_resolved=0
As a maintainer, I'd prefer to have a rpmlint message like
Your package contains foo.service, but no rcfoo symlink. You can create the rcfoo symlink by adding this line to your spec: ( mkdir -p %{buildroot}/usr/sbin && cd %{buildroot}/usr/sbin && ln -s service rcfoo ) and add the symlink to %files: /usr/sbin/rcfoo If you think a rcfoo symlink doesn't make sense for your package (for example because foo.service should never be started or stopped manually), add the following line to rpmlintrc: [copy&paste-ready line for rpmlintrc]
For a packager that would mean: build failure -> copy&paste from rpmlint message (to spec or rpmlintrc) -> success
I wouldn't call that annyoing - especially when the error message contains clear instructions what to do.
Ideally, yes. rpmlint messages in general do not contain detailed instructions to fix something though as it's kind of long winded to always change rpmlint code to match the current way of doing things. So the concrete instructions are usually here: http://en.opensuse.org/openSUSE:Packaging_checks
OTOH, I somehow doubt a manual bugreport (batchmode or not) will always contain that information - in other words: it's harder for the packager to handle it.
Also, especially with batch mode, you'll probably get a fresh bugreport some months later because you still didn't add a rc* symlink (for whatever reason) and the batch-reporter won't check bugzilla for old reports in 30 packages ;-)
You are already thinking one step ahead. I didn't even think of automating this batch filing. I'd be perfectely happy if we had a visual overview of the current state of rpmlint warnings, so humans could watch over this.
[1] for the packages I maintain, I could imagine to - list all "well-known" rpmlint warnings in rpmlintrc - add a special comment "# rpmlint-all-fatal" to the spec that makes _all_ _new_ rpmlint warnings fatal.
The advantage of this method would be to notice new warnings quickly [2], but I also know that it would mean lots of work to get it started. That's why I include "add a special comment to the spec to enable this behaviour" which means it's opt-in for each package(r).
What do you think about this idea?
I think a build failure is the wrong way to communicate non-fatal errors :-) A notification of new rpmlint warnings could be implemented without having to touch packages at all. You'd just need some service that fetches build logs regularly and notify the maintainers of changes in the rpmlint output.
[2] again: do you seriously think someone reads the build log if the build succeeds? ;-)
No, that's why there needs to be somebody that watches over the (interesting) non-fatal errors every once in a while. I'm sure such persons could be found if the information that allows to do the work is easily available. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (11)
-
Andrey Borzenkov -
Carlos E. R. -
Christian Boltz -
Cristian Rodríguez -
David Disseldorp -
Dominique Leuenberger a.k.a. Dimstar -
Dr. Werner Fink -
Ludwig Nussel -
Michal Hrusecky -
Robert Schweikert -
Wolfgang Rosenauer