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