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

On 9/3/13 4:22 PM, Greg KH wrote:

On Tue, Sep 03, 2013 at 03:34:06PM -0400, Jeff Mahoney wrote:

...

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.

Ok, so then just stick with what we have here, since when do people start running SLES kernels on openSUSE boxes and ask for support?

That's not what I'm trying to prevent, Greg. It's the random kernels that get built as part of other OBS projects, Tumbleweed, etc. People don't try to run SLES kernels on openSUSE boxes - but they do run a full SLES environment and then try to get support via openSUSE channels. Those get flushed out pretty quickly already and that's not the problem I'm trying to solve. As I said, I have a separate proposal already for the SLES kernel naming so that part of the problem is probably already solved.

A simple: $ rpm -qi kernel-desktop | grep Distribution Distribution: openSUSE:Tumbleweed should be able to detect what distro the kernel should be "for".

Again, I'm looking to avoid the feedback loop cycle. We want to make it easier for users to report bugs against releases and easier for those triaging those releases to determine if it's something we should be spending our time on.

...

The second is whether it's enough to put the information in the RPM metadata. I don't think it is.

Why not, it's already there with the "Distribution" tag. I thought that is what it is for, if not, what is that tag to be used for?

...

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.

Then why not just do this for SLES kernels, as that seems to be where you have worries about. Or just keep the list of "known valid" openSUSE kernels somewhere obvious so that the bugzilla triagers can weed things out.

More obvious than having the release string in the Oops itself? This is something that saves the triagers effort and costs the end user *nothing*. And then there's the issue of collisions between numbering of official releases and someone playing around with their own project but forgetting they installed a test kernel. Here's an example: someone taking a release kernel, grafting a new DRM subsystem onto it, and then filing bug reports against it when it didn't work right. It "looks" like an official release when you see the Oops but it most definitely is not.

...

...

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.

What makes the kernel so special? Why isn't this an issue for Samba? Libreoffice? mutt? :)

I suppose what makes it special is that I'm not the one doing first level triage for Samba, LibreOffice, or Mutt. If the maintainers of those projects want something similar, they can speak up. I'm not trying to tell them what will make their jobs easier -- I'm just identifying what will make mine easier.

...

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.

I think that's already there, see above.

It's not. The distribution tag isn't an "official" tag. It's a text string in the description field of the RPM. The ".dist" tag goes into the version string itself and can be passed into the package itself. We'd see packages like kernel-desktop-3.11.0-0.6.7.os131.x86_64.rpm but for every package, not just the kernel. -Jeff -- Jeff Mahoney SUSE Labs

On 9/3/13 5:07 PM, Andreas Schwab wrote:

Jeff Mahoney writes:

...

It's not. The distribution tag isn't an "official" tag. It's a text string in the description field of the RPM.

Wrong.

$ rpm -q --qf=%{DISTRIBUTION}\\n rpm openSUSE 12.3

Huh. Look at that. Regardless, it still doesn't get displayed in an Oops. -Jeff -- Jeff Mahoney SUSE Labs

On 9/3/13 5:16 PM, Greg KH wrote:

On Tue, Sep 03, 2013 at 04:57:47PM -0400, Jeff Mahoney wrote:

...

On 9/3/13 4:22 PM, Greg KH wrote:

...

On Tue, Sep 03, 2013 at 03:34:06PM -0400, Jeff Mahoney wrote:

...

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.

Ok, so then just stick with what we have here, since when do people start running SLES kernels on openSUSE boxes and ask for support?

That's not what I'm trying to prevent, Greg. It's the random kernels that get built as part of other OBS projects, Tumbleweed, etc. People don't try to run SLES kernels on openSUSE boxes - but they do run a full SLES environment and then try to get support via openSUSE channels. Those get flushed out pretty quickly already and that's not the problem I'm trying to solve. As I said, I have a separate proposal already for the SLES kernel naming so that part of the problem is probably already solved.

Ok, forget the SLES stuff, shouldn't be mentioned here at all :)

...

More obvious than having the release string in the Oops itself? This is something that saves the triagers effort and costs the end user *nothing*. And then there's the issue of collisions between numbering of official releases and someone playing around with their own project but forgetting they installed a test kernel. Here's an example: someone taking a release kernel, grafting a new DRM subsystem onto it, and then filing bug reports against it when it didn't work right. It "looks" like an official release when you see the Oops but it most definitely is not.

How are you going to prevent this from happening by adding the distro to the release number? That should be part of the spec file they just forked from the openSUSE:13.1 repo, so it should be added to their own "custom" kernel as well, right?

Or how are you suggesting it be added to the package, in a step not in OBS that anyone would not normally be able to do as part of the kernel build process?

Well that's the part that's interesting for discussion. :) My initial thought was just changing CONFIG_LOCALVERSION in config/* but that doesn't work for obvious reasons. Michal Marek suggested setting the .dist suffix off-list, which made me think that might be a workable way to do it. That's project-wide, though and needs deeper discussion. It might be possible to do it somehow within OBS with a project-specific variable that doesn't get cloned on project copy/branch. Getting into the details is the next step. I didn't want to dive in too deeply before getting past the "do we want to do this?" stage. -Jeff -- Jeff Mahoney SUSE Labs