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