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