Forbidding a double separator "-" in build/parseReqs.c is not always legitimate

[grizzlyfred]

I must use debian stretch, which now is on 2014's (!) rpm 4.12.
Upgrading to 4.14 via deb is prohibitive, and building 4.14 on stretch fails due to line 20048 in the configure script "unknown token ZSTD". This is all probably due to the fact that debian stable means totally outdated versions, here something in the autoconf toolchain in debian may not know zstd compressor yet?

However, at least 4.13 kernel is available in backports, named 4.13.0-0.bpo.1-amd64

In 2013 there was a version check introduced with this commit:
b2cf147

and then 4.12 was released 2014

... and there is a #DEFINE return value since 2015 with commit
5e94633

The hard error instead of a warning in turn breaks my build of ZFS >=0.7.4 which I need to open my already partially crypted pool... (how did I manage to build that I wonder?)

So much for the context. I know the culprit is rather debian being "stable" meaning having only old bugs the world has long solved and not the new ones not yet solved or discovered... ;-)

BUT: Actually I do not think their kernel version number as such is invalid - only the check is too simple:
4.13.0 is the kernel version part, the -0 is the deb patch level, .bpo. means backport .1 probably build one and -amd64 is the platform - so in the special case where rpm is used to make alien deb packages, it should imo not enforce any versioning scheme resp. it cannot know all of them. And especially that is only the info against which kernel the alien deb package is made...

I think it is now quite common to add -platform or -gitVersion or even -ISODATE to versions, so I think rpm may warn but not enforce a certain scheme OR at least accept platform-suffixes etc. I think that the current check is to simplistic and a fully-fledged regex check for all thinkable versioning schemes not feasible.

Thus I question the value of the check - it wouldn't bother me could I build my own rpm version to build my own debian zfsonlinux but alas the ZSTD token ... I suggest removing that check, it serves no real purpose imo and just limits the usability of the rpm toolkit.

[pmatilai]

Ehm. Long story short, care to provide an actual example of a version where you think double dash is legitimate?

[pmatilai]

Double-ehm... shouldn't reply anything before two cups of coffee in the morning.

The dash is the the separator charactor of name, version and release in rpm, parsing from end of the string. And because of that, a double dash is simply never legitimate in release or version. And dpkg is mostly the same (http://www.fifi.org/doc/debian-policy/policy.html/ch-versions.html) with a couple of exceptions, maybe this is about those.

In any case, a tool claiming to convert between package formats simply has to know about the package format versioning, that's it's job and if it fails to do it then it's a bug in alien, not in the package formats.

[mlschroe]

(The 'alien' tool could simply turn off that check by setting %_wrong_version_format_terminate_build to zero in the generated spec file.)

[grizzlyfred]

I am at a loss as to what this means? Is it a bug in alien? The kernel was named 4.13.0-0.bpo.1-amd64 with two dashes...