[opensuse-kernel] kernel-desktop-2.6.31-7.1.x86_64 obsoletes kernel-desktop-base
I am of the understanding that kernel-desktop normally requires kernel-desktop-base but now it obsoletes it. Is this a new feature or a bug? Regards Dave P -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Sat, Sep 26, 2009 at 09:03:32AM +0200, Dave Plater wrote:
I am of the understanding that kernel-desktop normally requires kernel-desktop-base but now it obsoletes it. Is this a new feature or a bug?
The -base subpackage is back in the main kernel package. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 09/26/2009 09:59 AM, Marcus Meissner wrote:
On Sat, Sep 26, 2009 at 09:03:32AM +0200, Dave Plater wrote:
I am of the understanding that kernel-desktop normally requires kernel-desktop-base but now it obsoletes it. Is this a new feature or a bug?
The -base subpackage is back in the main kernel package.
Ciao, Marcus
So is kernel-desktop-base-2.6.31-7.1.x86_64 still being in factory repo a bug or is it there for another reason? Regards Dave P -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 09/26/2009 12:59 AM, Marcus Meissner wrote:
On Sat, Sep 26, 2009 at 09:03:32AM +0200, Dave Plater wrote:
I am of the understanding that kernel-desktop normally requires kernel-desktop-base but now it obsoletes it. Is this a new feature or a bug?
The -base subpackage is back in the main kernel package.
That's not the complete explanation. The real story is this: For SLE11, we wanted to have multiple kernel packages that fulfilled a few goals 1) stop wasting space on virtualized guests and 2) don't install unsupported modules by default. 1) was accomplished with the -base package. 2) was accomplished with the -extra package. The thing is that 2) makes *no* sense on openSUSE since there isn't a concept of supported vs. unsupported. I added a patch a month or two ago that made that option configurable so openSUSE users don't have to deal with the meaningless noise. 1) still exists on openSUSE, so it made sense to keep it around. The thing is that it's _annoying_ to install both $flavor-base and $flavor since $flavor-base can be installed on its own and then it tries to run a mkinitrd on a system that may not be completely installed yet. I don't recall the bug number off the top of my head, but I've seen it a few times where users report "FATAL: can't find module ..." It turns out that the condition isn't fatal in that case but there's no easy way to convey that to the user or suppress the message in the case that kernel-$flavor will be installed on top of kernel-$flavor-base. RPM allows you to put files in multiple packages built from the same spec file. Not only unique files, but duplicate files too. So instead of having a kernel-$flavor and kernel-$flavor-base with a dependency link, now you need one or the other depending on your need. It takes up slightly more space on the install media but improves the user experience. If you had kernel-$flavor installed before, then that's all you'll need. If you ONLY had kernel-$flavor-base installed before, then that's all you'll need. -Jeff -- Jeff Mahoney SuSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 09/26/2009 07:13 PM, Jeff Mahoney wrote:
On 09/26/2009 12:59 AM, Marcus Meissner wrote:
On Sat, Sep 26, 2009 at 09:03:32AM +0200, Dave Plater wrote:
I am of the understanding that kernel-desktop normally requires kernel-desktop-base but now it obsoletes it. Is this a new feature or a bug?
The -base subpackage is back in the main kernel package.
That's not the complete explanation. The real story is this: For SLE11, we wanted to have multiple kernel packages that fulfilled a few goals 1) stop wasting space on virtualized guests and 2) don't install unsupported modules by default.
1) was accomplished with the -base package. 2) was accomplished with the -extra package. The thing is that 2) makes *no* sense on openSUSE since there isn't a concept of supported vs. unsupported. I added a patch a month or two ago that made that option configurable so openSUSE users don't have to deal with the meaningless noise. 1) still exists on openSUSE, so it made sense to keep it around.
The thing is that it's _annoying_ to install both $flavor-base and $flavor since $flavor-base can be installed on its own and then it tries to run a mkinitrd on a system that may not be completely installed yet. I don't recall the bug number off the top of my head, but I've seen it a few times where users report "FATAL: can't find module ..." It turns out that the condition isn't fatal in that case but there's no easy way to convey that to the user or suppress the message in the case that kernel-$flavor will be installed on top of kernel-$flavor-base.
RPM allows you to put files in multiple packages built from the same spec file. Not only unique files, but duplicate files too. So instead of having a kernel-$flavor and kernel-$flavor-base with a dependency link, now you need one or the other depending on your need. It takes up slightly more space on the install media but improves the user experience. If you had kernel-$flavor installed before, then that's all you'll need. If you ONLY had kernel-$flavor-base installed before, then that's all you'll need.
-Jeff
If I had accepted the base package instead of the bigger one and it didn't support my xfs root wouldn't I have had a problem? Overall it makes sense to have a unified package, it certainly solves the error message problem, I'm just curious as to why there is still an x86_64 and i586 kernel-desktop-base package as well. Regards Dave P -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 09/27/2009 05:48 AM, Dave Plater wrote:
On 09/26/2009 07:13 PM, Jeff Mahoney wrote:
On 09/26/2009 12:59 AM, Marcus Meissner wrote:
On Sat, Sep 26, 2009 at 09:03:32AM +0200, Dave Plater wrote:
I am of the understanding that kernel-desktop normally requires kernel-desktop-base but now it obsoletes it. Is this a new feature or a bug?
The -base subpackage is back in the main kernel package.
That's not the complete explanation. The real story is this: For SLE11, we wanted to have multiple kernel packages that fulfilled a few goals 1) stop wasting space on virtualized guests and 2) don't install unsupported modules by default.
1) was accomplished with the -base package. 2) was accomplished with the -extra package. The thing is that 2) makes *no* sense on openSUSE since there isn't a concept of supported vs. unsupported. I added a patch a month or two ago that made that option configurable so openSUSE users don't have to deal with the meaningless noise. 1) still exists on openSUSE, so it made sense to keep it around.
The thing is that it's _annoying_ to install both $flavor-base and $flavor since $flavor-base can be installed on its own and then it tries to run a mkinitrd on a system that may not be completely installed yet. I don't recall the bug number off the top of my head, but I've seen it a few times where users report "FATAL: can't find module ..." It turns out that the condition isn't fatal in that case but there's no easy way to convey that to the user or suppress the message in the case that kernel-$flavor will be installed on top of kernel-$flavor-base.
RPM allows you to put files in multiple packages built from the same spec file. Not only unique files, but duplicate files too. So instead of having a kernel-$flavor and kernel-$flavor-base with a dependency link, now you need one or the other depending on your need. It takes up slightly more space on the install media but improves the user experience. If you had kernel-$flavor installed before, then that's all you'll need. If you ONLY had kernel-$flavor-base installed before, then that's all you'll need.
-Jeff
If I had accepted the base package instead of the bigger one and it didn't support my xfs root wouldn't I have had a problem? Overall it makes sense to have a unified package, it certainly solves the error message problem, I'm just curious as to why there is still an x86_64 and i586 kernel-desktop-base package as well.
Yeah, you would've had a problem because it wouldn't have been the right kernel for your system. Did it offer that as a higher priority option? The base package exists for users who want to use virtualized systems but don't want to waste the space of storing all the modules they'll never use. It's sort of a baseline in that it only contains the bare essentials for the most common virtualized use cases (i.e. ext3, disks, MD, DM, loopback). The package set can be changed based on feedback, though. -Jeff -- Jeff Mahoney SuSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 09/27/2009 05:22 PM, Jeff Mahoney wrote:
On 09/27/2009 05:48 AM, Dave Plater wrote:
On 09/26/2009 07:13 PM, Jeff Mahoney wrote:
On 09/26/2009 12:59 AM, Marcus Meissner wrote:
On Sat, Sep 26, 2009 at 09:03:32AM +0200, Dave Plater wrote:
I am of the understanding that kernel-desktop normally requires kernel-desktop-base but now it obsoletes it. Is this a new feature or a bug?
The -base subpackage is back in the main kernel package.
That's not the complete explanation. The real story is this: For SLE11, we wanted to have multiple kernel packages that fulfilled a few goals 1) stop wasting space on virtualized guests and 2) don't install unsupported modules by default.
1) was accomplished with the -base package. 2) was accomplished with the -extra package. The thing is that 2) makes *no* sense on openSUSE since there isn't a concept of supported vs. unsupported. I added a patch a month or two ago that made that option configurable so openSUSE users don't have to deal with the meaningless noise. 1) still exists on openSUSE, so it made sense to keep it around.
The thing is that it's _annoying_ to install both $flavor-base and $flavor since $flavor-base can be installed on its own and then it tries to run a mkinitrd on a system that may not be completely installed yet. I don't recall the bug number off the top of my head, but I've seen it a few times where users report "FATAL: can't find module ..." It turns out that the condition isn't fatal in that case but there's no easy way to convey that to the user or suppress the message in the case that kernel-$flavor will be installed on top of kernel-$flavor-base.
RPM allows you to put files in multiple packages built from the same spec file. Not only unique files, but duplicate files too. So instead of having a kernel-$flavor and kernel-$flavor-base with a dependency link, now you need one or the other depending on your need. It takes up slightly more space on the install media but improves the user experience. If you had kernel-$flavor installed before, then that's all you'll need. If you ONLY had kernel-$flavor-base installed before, then that's all you'll need.
-Jeff
If I had accepted the base package instead of the bigger one and it didn't support my xfs root wouldn't I have had a problem? Overall it makes sense to have a unified package, it certainly solves the error message problem, I'm just curious as to why there is still an x86_64 and i586 kernel-desktop-base package as well.
Yeah, you would've had a problem because it wouldn't have been the right kernel for your system. Did it offer that as a higher priority option?
The base package exists for users who want to use virtualized systems but don't want to waste the space of storing all the modules they'll never use. It's sort of a baseline in that it only contains the bare essentials for the most common virtualized use cases (i.e. ext3, disks, MD, DM, loopback). The package set can be changed based on feedback, though.
-Jeff
When I used zypper up kernel-desktop* as I usually do to update the three kernel packages it offered me a choice of either kernel-desktop or kernel-desktop-base as did yast when I selected update all in this list if a newer version is available. I suppose I should file a bug that the installation system should check for needed drivers that aren't in the base package. On the other hand, if somebody updates from 11.1 will zypper dup handle it properly? Regards Dave P -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Dave Plater napsal(a):
When I used zypper up kernel-desktop* as I usually do to update the three kernel packages it offered me a choice of either kernel-desktop or kernel-desktop-base as did yast when I selected update all in this list if a newer version is available. I suppose I should file a bug that the installation system should check for needed drivers that aren't in the base package. On the other hand, if somebody updates from 11.1 will zypper dup handle it properly?
When I added the Obsoletes:, I tested that a 'zypper dup' gets it right (i.e. upgrades kernel-$flavor and deletes kernel-$flavor-base, I think it also got it right if there was only kernel-$flavor-base originally). This has to work and I hope it hasn't changed since then. Having 'zypper up kernel-desktop*' do the same right thing would be also nice, but it's not what users upgrading from 11.1 to 11.2 will be doing. I think the difference is that is that zypper expands 'up kernel-desktop*' to 'up kernel-desktop kernel-desktop-base', which can't be resolved (you want to update kernel-desktop, which obsoletes kernel-desktop-base, which you want to update at the same time). Of course, if you come up with a Obsoletes: line that does the right thing in all possible scenarios, then I'm all for it, but currently I'm happy that it at least works with 'zypper dup'. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 09/29/2009 11:16 AM, Michal Marek wrote:
Dave Plater napsal(a):
When I used zypper up kernel-desktop* as I usually do to update the three kernel packages it offered me a choice of either kernel-desktop or kernel-desktop-base as did yast when I selected update all in this list if a newer version is available. I suppose I should file a bug that the installation system should check for needed drivers that aren't in the base package. On the other hand, if somebody updates from 11.1 will zypper dup handle it properly?
When I added the Obsoletes:, I tested that a 'zypper dup' gets it right (i.e. upgrades kernel-$flavor and deletes kernel-$flavor-base, I think it also got it right if there was only kernel-$flavor-base originally). This has to work and I hope it hasn't changed since then. Having 'zypper up kernel-desktop*' do the same right thing would be also nice, but it's not what users upgrading from 11.1 to 11.2 will be doing. I think the difference is that is that zypper expands 'up kernel-desktop*' to 'up kernel-desktop kernel-desktop-base', which can't be resolved (you want to update kernel-desktop, which obsoletes kernel-desktop-base, which you want to update at the same time). Of course, if you come up with a Obsoletes: line that does the right thing in all possible scenarios, then I'm all for it, but currently I'm happy that it at least works with 'zypper dup'.
Michal
If dup handles it properly then there's not a problem. Now I've updated (good thing I was sensible enough to pick the right package) things will be back to normal. Interesting thing is, I keep multiple kernels and when I used zypper rm kernel-default-base"<=2.6.30" it automatically installed the new kernel-default, normally it just removes the kernel packages. Regards Dave P -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (4)
-
Dave Plater -
Jeff Mahoney -
Marcus Meissner -
Michal Marek