On 9/3/13 1:40 PM, Greg KH wrote:
On Tue, Sep 03, 2013 at 01:31:38PM -0400, Jeff Mahoney wrote:
Hi all -
One of the things I'd like to consider for openSUSE 13.1 is changing the naming scheme to include the release in the uname -r output so that when there is a version collision between openSUSE and SLES, we can tell the difference. I've introduced a similar proposal for the naming change to the SLES kernels, so this isn't a case of making the distinction only with openSUSE.
So instead of:
3.7.10-1.11-default
We could have:
3.7.10-1.11.oS12.3-default
I suppose the kernel release for Factory would be: 3.7.10-1.11.oSF-default
And what about tumbleweed, which just takes directly from Kernel:Stable? Will you do this for all targets the kernel builds on?
If so, that doesn't make much sense, as the kernel package is pretty independant of the different releases.
The fact that you just happen to use the same kernel version number for SLES and openSUSE, doesn't mean you should put that in the version number, it will show up in the rpm metadata.
Ok, so there are two things here. The first is whether the goal is to identify arbitrary kernels. From my perspective, it's not. I only want to be able to identify kernels that are part of the official release and, as such, kernels that are under the limited amount of maintenance and support we offer for openSUSE. I don't want to try to architect a 'perfect' (as in the enemy of good) solution that handles all the special cases because it's enough for me to know that a kernel package with the version of 3.7.x is or isn't from the 12.3 release stream. I suppose there's a certain amount of trust involved in assuming that if it has the oS12.3 string in the release that it's a 12.3 kernel. I'm just looking for easy identification not cryptographic certainty. I don't want to chase ghosts from kernels that have been built and published somewhere, even somewhere semi-official, but for which we've never said we'll do anything to support. The second is whether it's enough to put the information in the RPM metadata. I don't think it is. We have that now with the Git commit and Branch tags in the package description. The goal is for tools like uname -r to show the distinction at runtime and for mechanisms like Oopes and WARN_ONs to show it when the kernel fails. I'd like them to be easily and uniquely identifiable as official releases without adding another error-prone feedback loop into the bug reporting cycle.
Unless this is going to change for all packages in SLES I don't see the benefit for openSUSE.
I must not understand the point you're trying to make here. I don't see why it makes any difference for any packages other than kernel packages for this case. Perhaps the answer isn't to change it in the version string in the package but to enable the .dist tag for the RPMs built in official releases so that the kernel inherits it automatically. -Jeff -- Jeff Mahoney SUSE Labs