[Rpm-maint] [rpm-software-management/rpm] Forbidding a double separator "-" in build/parseReqs.c is not always legitimate (#369)

grizzlyfred notifications at github.com
Wed Dec 13 00:11:19 UTC 2017


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:
b2cf1471bbe2c35e3c36510a9e3f59919d8ed2c8

and then 4.12 was released 2014

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

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/369
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20171212/bade998f/attachment.html>


More information about the Rpm-maint mailing list