Re: Re: Third-Party Software Needs Non-Debian Format for Kernel Version
>>> isn't supported per se. But when [the software], or the makefiles,
>>> parse the string
>>> 3.12-1-amd64
>>> they don't get the expected result. If the uname -r were the string
>>> 3.12.9-1
>>> then parsing it would yield the expected result.
>>> ---END QUOTE FROM VENDOR---
>>>
>>> Is the reported kernel-version string, "3.12-1-amd64", something
>>> that I could change by compiling a custom kernel?
>>
>> Might a shell script that output the expected string work?
>
> Or link or what ever? I don't understand what the software is doing,
> that the output of uname -r doesn't fit to some other string.
I think that the build system is using the uname(1) command, but the
compiled software is calling the uname(2) system call.
> More information is needed.
I have not very much information, but let's assume the worst: The vendor
has some compiled code that calls the uname() system call.
Is it possible by compiling a custom kernel for me to make what uname()
returns be the format that the vendor desires, something like '3.12.9-1', or
whatever?
> Sure, Debian packages might be named 3.x for kernels 3.x.y, 3.x.z,
> 3.x.n. I like this, since I don't need to manually fix my manually
> customized grub.cfg, when such a kernel is upgraded and especially those
> kernels are updated and older versions automatically will be removed,
> while kernels build by myself are never touched.
I'm not sure that I understand. The package name is one thing, but isn't
what uname returns something else?
--
Thomas E. Vaughan
Reply to: