[opensuse-packaging] BETA: watch out for new rpmlint fun
Hi, externals: stop reading here. Hopefully soon the new rpmlint checks will be enabled in BETA, which might be more strict and can cause new packages to fail. There was no particular new check added, just that some of the slow brp scripts were rewritten and integrated into rpmlint for performance and ease of maintenance. There might be fallout: false positives and false negatives. Please let me know if you find anything particularly interesting so that I can improve the checks. Thanks, Dirk :-) -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dirk Mueller escribió:
There might be fallout: false positives and false negatives.
getting one.. dot-in-identifier Obsoletes: libgpod <= 0.4.2 For buildsystem internal reasons, suse disallows the usage of dot's in dependency tokens (package names, provides, requires and similar). Please rename the token. 0.4.2 is a version number which seems to be a pretty normal versioned Obsoletes.. -- “There is always some madness in love. But there is also always some reason in madness.” - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Saturday 09 February 2008, Cristian Rodríguez wrote:
dot-in-identifier Obsoletes: libgpod <= 0.4.2
Already fixed, thanks. -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le vendredi 08 février 2008, Dirk Mueller a écrit :
Hopefully soon the new rpmlint checks will be enabled in BETA, which might be more strict and can cause new packages to fail. There was no particular new check added, just that some of the slow brp scripts were rewritten and integrated into rpmlint for performance and ease of maintenance.
There might be fallout: false positives and false negatives. Please let me know if you find anything particularly interesting so that I can improve the checks.
Got this error this morning: sensors.src:99: E: dot-in-identifier (Badness: 10000) Provides: sensors:/usr/include/sensors/sensors.h For buildsystem internal reasons, suse disallows the usage of dot's in dependency tokens (package names, provides, requires and similar). Please rename the token. This seems to be the standard way to handle package splits, this provides statement was suggested to me by Stephan Kulow. Is this a false positive in rpmlint, or is there a new syntax to handle this case? Thanks, -- Jean Delvare Suse L3 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, 15 Feb 2008, Jean Delvare wrote:
Le vendredi 08 février 2008, Dirk Mueller a écrit :
Hopefully soon the new rpmlint checks will be enabled in BETA, which might be more strict and can cause new packages to fail. There was no particular new check added, just that some of the slow brp scripts were rewritten and integrated into rpmlint for performance and ease of maintenance.
There might be fallout: false positives and false negatives. Please let me know if you find anything particularly interesting so that I can improve the checks.
Got this error this morning:
sensors.src:99: E: dot-in-identifier (Badness: 10000) Provides: sensors:/usr/include/sensors/sensors.h For buildsystem internal reasons, suse disallows the usage of dot's in dependency tokens (package names, provides, requires and similar). Please rename the token.
This seems to be the standard way to handle package splits, this provides statement was suggested to me by Stephan Kulow. Is this a false positive in rpmlint, or is there a new syntax to handle this case?
no, your example is perfectly fine. Actually, the dots are only unwanted in package names, and for a safety check we wanted to block the same thing in requires. But a Requires: foo >= 1.0 is something completely different than Requires: foo-1.0 where the top one requires a package of name "foo" in version at least "1.0" and the lower one requires a package of name "foo-1.0" in any version. Provides in general and the split-provides are a different story. Unsolved is the Requiring of path-names. Probably the rule should be: To be consistent with the "." not being wanted in a package name, a requires should not contain a "." in the REQUIRENAME unless that provides also contains a "/". -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux Fatou 2.6.24-8-default #1 SMP 2008/02/08 10:55:16 UTC x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
On Friday 15 February 2008, Ruediger Oertel wrote:
To be consistent with the "." not being wanted in a package name, a requires should not contain a "." in the REQUIRENAME unless that provides also contains a "/".
well, "foo/bar.h" would still be invalid. I've just updated the check to ignore the path part of split-provides, that should help in this case. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, 15 Feb 2008, Dirk Mueller wrote:
On Friday 15 February 2008, Ruediger Oertel wrote:
To be consistent with the "." not being wanted in a package name, a requires should not contain a "." in the REQUIRENAME unless that provides also contains a "/".
well, "foo/bar.h" would still be invalid. I've just updated the check to ignore the path part of split-provides, that should help in this case.
well, I meant to _only_ check requires and not provides. -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux Fatou 2.6.24-8-default #1 SMP 2008/02/08 10:55:16 UTC x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
On Friday 15 February 2008, Ruediger Oertel wrote:
well, "foo/bar.h" would still be invalid. I've just updated the check to ignore the path part of split-provides, that should help in this case. well, I meant to _only_ check requires and not provides.
and not conflicts either? and not obsoletes? and not recommends? and not enhances? Thanks, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, 15 Feb 2008, Dirk Mueller wrote:
On Friday 15 February 2008, Ruediger Oertel wrote:
well, "foo/bar.h" would still be invalid. I've just updated the check to ignore the path part of split-provides, that should help in this case. well, I meant to _only_ check requires and not provides.
and not conflicts either? and not obsoletes? and not recommends? and not enhances?
requires, recommends, suggests: yes provides, supplements, enhances: no (don't check) conflicts, obsoletes: probably yes -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux Fatou 2.6.24-8-default #1 SMP 2008/02/08 10:55:16 UTC x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
participants (4)
-
Cristian Rodríguez -
Dirk Mueller -
Jean Delvare -
Ruediger Oertel