Home_greyopenFATE - openSUSE feature tracking > #307154
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

merge kernel-$flavor-base back to kernel-$flavor

Feature state

openSUSE-11.2
Done
openSUSE-11.3
Done

Description

The split of the kernel package (Feature #303631) has a number of annoying side effects, such as 1) reduced installation time, 2) lots of error messages printed by mkinitrd when the -base package is installed and 3) a failure (e.g. network down) during installation of kernel-$flavor will result in a non-bootable system. The benefit of the -extra subpackage is that unsupported modules can be excluded from SLES media, which is good, but the -base package seems to cause more harm than good (it was intended for PV guest installs, but it's unclear whether it's actually used that way).

References

Bug #491959 - installation of kernel-default-base produces lot of FATAL errors: https://bugzilla.novell.com/491959

Bug #513841 - include vfat in kernel-*-base: https://bugzilla.novell.com/513841

Testcase

An update from 11.1 should remove the kernel-*-base and kernel-*-extra packages and the system boots with all needed modules.

Discussion


icons/user_comment.png M. M. wrote: (8 years ago)

It turns out that we can eat the cake AND have it, namely that rpmbuild allows subpackages to overlap. So we can have kernel-$flavor-base for virtual guests and kernel-$flavor as a superset of -base. The only drawback would be a few duplicated megabytes on mirrors.

icons/user_comment.png S. K. wrote: (8 years ago)

I'm all for it, but when -base changes its semantic (i.e. conflicts with kernel-flavor) then we need to have this in for m6.

icons/user_comment.png J. E. wrote: (8 years ago)

I with you on your original comment. The split at best made sense for Novell-internal workflows, outside that, I am not sure what benefits it brought.

There are a few small disk space savings -- granted nobody has TokenRing these days -- but it's just a drop on the hot stone.

icons/user_comment.png M. M. wrote: (8 years ago)

I need some advice from a solver guru here: The new kernel-$flavor contains everything that kernel-$flavor-base contains. So when updating from a 11.1 with kernel-$flavor-base and kernel-$flavor, kernel-$flavor-base should be deleted and kernel-$flavor updated. When updating a system which only had kernel-$flavor-base, it should be simply updated. At the same time, I don't want to disrupt the ability to install multiple kernel versions in parallel. And here comes the problem: if kernel-$flavor has

Provides:       %name-base = %version-%release 
Obsoletes: %name-base = %version-%release

zypper dup complains

# zypper dup -r kernel-test1 
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
Problem: kernel-default-2.6.31-1.x86_64 obsoletes kernel-default-base = 2.6.31-1 provided by kernel-default-base-2.6.31-1.x86_64
Solution 1: deinstallation of kernel-default-2.6.27.23-0.1.1.x86_64
Solution 2: keep kernel-default-base-2.6.27.23-0.1.1.x86_64
Choose from above solutions by number or cancel [1/2/C]: c

If I replace it with

Conflicts:      %name-base = %version-%release

then it goes like this

# zypper dup -r kernel-test2 
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
Problem: kernel-default-2.6.31-1.x86_64 conflicts with kernel-default-base = 2.6.31-1 provided by kernel-default-base-2.6.31-1.x86_64
Solution 1: deinstallation of kernel-default-2.6.27.23-0.1.1.x86_64
Solution 2: keep kernel-default-base-2.6.27.23-0.1.1.x86_64
Choose from above solutions by number or cancel [1/2/C]: c

In both cases Solution 1 is the right one, but zypper asks nevetheless. Michael, do you have an idea?

icons/user_comment.png M. M. wrote: (8 years ago)

So far all attemps resulted either in

a) zypper dup updating both main and base

b) zypper dup updating main even if there was only base previously

c) zypper dup trying to update both and complaning that they conflict (if I add a Conflicts:)

Even renaming the new base subpackage to something else leads to b) :-/

icons/user_comment.png M. M. wrote: (8 years ago)

I gave up on the dependencies for now, updating to M6 will keep both the main and base subpackage, with all the above mentioned problems, but it shouldn't be any worse than before. A fresh install will benefit from this feature, there won't be any kernel-*-base anymore. Doing it this way allows us to solve the update from 11.1 (base should be removed) later, without having to work around any intermediate hacks.

I opened https://bugzilla.novell.com/530752 to track the update problem.

icons/user_comment.png M. M. wrote: (8 years ago)

307154/">http://labs.suse.cz/mmarek/Fate #307154/ has the two test repositories for x86_64.

icons/user_comment.png M. M. wrote: (8 years ago)

deleted.

Last change: 8 years ago
Voting
Score: 4
  • Negative: 0
  • Neutral: 0
  • Positive: 4
Tags
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint