On Tuesday 2017-04-25 13:40, Stephan Kulow wrote:
On 25.04.2017 13:29, Jan Engelhardt wrote:
Yesyes, you posted a solution to the %macro problems, but I am still keen on hearing your nondestructive solution for /etc/os-release's VERSION_ID, if there is any.
While I understand you insist on increasing version numbers, I don't really see too many technical arguments for it actually.
Because most real life cases I can think of won't be able to use a reliable > no matter how often openSUSE screws version numbers anyway. Because you just don't know any details about future versions.
It's not about future versions but past ones: if (v < 1200) dit; else if (v < 1300) dat; else if (v < 4200) dot; else { current practice, hope that it will work for enough future versions until the next script revision is out } Should they have written ">= x00 && <= xx99" instead? Maybe. Either way, they could have not know that 1500 would come along.
I.e. normally you support X versions/platforms and form your conditionals based on that. So a >= 1500 && < 4200 will bring you a while.
Especially as Tumbleweed has 20170417 in there, you will need some extra logic anyway to support openSUSE releases in a broader sense.
case "$NAME" in "openSUSE Leap") if (v < 4200 ) echo "Your glibc is too old" "openSUSE Tumbleweed") if (v < 20170000) echo "Your zen is too old" esac -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org