[openFATE 307154] merge kernel-$flavor-base back to kernel-$flavor
Feature added by: Michal Marek (michal-m) Feature #307154, revision 1 Title: merge kernel-$flavor-base back to kernel-$flavor openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Michal Marek (michal-m) 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). -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Michal Marek (michal-m) Feature #307154, revision 2 Title: merge kernel-$flavor-base back to kernel-$flavor openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Michal Marek (michal-m) 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 + Bug 513841 -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Michal Marek (michal-m) Feature #307154, revision 3 Title: merge kernel-$flavor-base back to kernel-$flavor openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Michal Marek (michal-m) 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 - Bug 513841 + 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 -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Michal Marek (michal-m) Feature #307154, revision 4 Title: merge kernel-$flavor-base back to kernel-$flavor openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Michal Marek (michal-m) 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 + Discussion: + #1: Michal Marek (michal-m) (2009-08-05 13:21:09) + 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. -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Michal Marek (michal-m) Feature #307154, revision 5 Title: merge kernel-$flavor-base back to kernel-$flavor - openSUSE-11.2: Unconfirmed + openSUSE-11.2: New Priority Requester: Important - openSUSE-11.3: Unconfirmed + openSUSE-11.3: New Priority Requester: Important Requested by: Michal Marek (michal-m) 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 Discussion: #1: Michal Marek (michal-m) (2009-08-05 13:21:09) 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. -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Jan Engelhardt (jengelh) Feature #307154, revision 6 Title: merge kernel-$flavor-base back to kernel-$flavor openSUSE-11.2: New Priority Requester: Important openSUSE-11.3: New Priority Requester: Important Requested by: Michal Marek (michal-m) 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 Discussion: #1: Michal Marek (michal-m) (2009-08-05 13:21:09) 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. + #2: Jan Engelhardt (jengelh) (2009-08-06 13:59:45) + 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. -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Andreas Jaeger (a_jaeger) Feature #307154, revision 7 Title: merge kernel-$flavor-base back to kernel-$flavor - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important openSUSE-11.3: New Priority Requester: Important Requested by: Michal Marek (michal-m) 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 Discussion: #1: Michal Marek (michal-m) (2009-08-05 13:21:09) 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. #2: Jan Engelhardt (jengelh) (2009-08-06 13:59:45) 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. -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Stephan Kulow (coolo) Feature #307154, revision 8 Title: merge kernel-$flavor-base back to kernel-$flavor - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Important + Projectmanager: Important openSUSE-11.3: New Priority Requester: Important Requested by: Michal Marek (michal-m) 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 Discussion: #1: Michal Marek (michal-m) (2009-08-05 13:21:09) 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. + #3: Stephan Kulow (coolo) (2009-08-12 11:44:16) (reply to #1) + 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. #2: Jan Engelhardt (jengelh) (2009-08-06 13:59:45) 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. -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Michal Marek (michal-m) Feature #307154, revision 10 Title: merge kernel-$flavor-base back to kernel-$flavor openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Important Requested by: Michal Marek (michal-m) 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 Discussion: #1: Michal Marek (michal-m) (2009-08-05 13:21:09) 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. #3: Stephan Kulow (coolo) (2009-08-12 11:44:16) (reply to #1) 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. #2: Jan Engelhardt (jengelh) (2009-08-06 13:59:45) 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. + #4: Michal Marek (michal-m) (2009-08-12 16:22:15) + 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? -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Michal Marek (michal-m) Feature #307154, revision 11 Title: merge kernel-$flavor-base back to kernel-$flavor openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Important Requested by: Michal Marek (michal-m) 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 Discussion: #1: Michal Marek (michal-m) (2009-08-05 13:21:09) 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. #3: Stephan Kulow (coolo) (2009-08-12 11:44:16) (reply to #1) 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. #2: Jan Engelhardt (jengelh) (2009-08-06 13:59:45) 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. #4: Michal Marek (michal-m) (2009-08-12 16:22:15) 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? + #5: Michal Marek (michal-m) (2009-08-12 16:25:31) + http://labs.suse.cz/mmarek/fate307154/ has the two test repositories + for x86_64. -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Michal Marek (michal-m) Feature #307154, revision 12 Title: merge kernel-$flavor-base back to kernel-$flavor openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Important Requested by: Michal Marek (michal-m) 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 Discussion: #1: Michal Marek (michal-m) (2009-08-05 13:21:09) 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. #3: Stephan Kulow (coolo) (2009-08-12 11:44:16) (reply to #1) 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. #2: Jan Engelhardt (jengelh) (2009-08-06 13:59:45) 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. #4: Michal Marek (michal-m) (2009-08-12 16:22:15) 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? + #6: Michal Marek (michal-m) (2009-08-13 10:32:48) (reply to #4) + 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) :- + / #5: Michal Marek (michal-m) (2009-08-12 16:25:31) http://labs.suse.cz/mmarek/fate307154/ has the two test repositories for x86_64. -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Michal Marek (michal-m) Feature #307154, revision 13 Title: merge kernel-$flavor-base back to kernel-$flavor - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important - openSUSE-11.3: New + openSUSE-11.3: Done Priority Requester: Important Requested by: Michal Marek (michal-m) 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 Discussion: #1: Michal Marek (michal-m) (2009-08-05 13:21:09) 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. #3: Stephan Kulow (coolo) (2009-08-12 11:44:16) (reply to #1) 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. #2: Jan Engelhardt (jengelh) (2009-08-06 13:59:45) 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. #4: Michal Marek (michal-m) (2009-08-12 16:22:15) 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? #6: Michal Marek (michal-m) (2009-08-13 10:32:48) (reply to #4) 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) :- / + #7: Michal Marek (michal-m) (2009-08-13 12:49:10) (reply to #6) + 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. #5: Michal Marek (michal-m) (2009-08-12 16:25:31) http://labs.suse.cz/mmarek/fate307154/ has the two test repositories for x86_64. + #8: Michal Marek (michal-m) (2009-08-13 11:31:09) (reply to #5) + deleted. -- openSUSE Feature: https://features.opensuse.org/307154
Feature changed by: Michal Marek (michal-m) Feature #307154, revision 14 Title: merge kernel-$flavor-base back to kernel-$flavor openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important openSUSE-11.3: Done Priority Requester: Important Requested by: Michal Marek (michal-m) 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 + Test Case: + An update from 11.1 should remove the kernel-*-base and kernel-*-extra + packages and the system boots with all needed modules. Discussion: #1: Michal Marek (michal-m) (2009-08-05 13:21:09) 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. #3: Stephan Kulow (coolo) (2009-08-12 11:44:16) (reply to #1) 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. #2: Jan Engelhardt (jengelh) (2009-08-06 13:59:45) 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. #4: Michal Marek (michal-m) (2009-08-12 16:22:15) 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? #6: Michal Marek (michal-m) (2009-08-13 10:32:48) (reply to #4) 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) :- / #7: Michal Marek (michal-m) (2009-08-13 12:49:10) (reply to #6) 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. #5: Michal Marek (michal-m) (2009-08-12 16:25:31) http://labs.suse.cz/mmarek/fate307154/ has the two test repositories for x86_64. #8: Michal Marek (michal-m) (2009-08-13 11:31:09) (reply to #5) deleted. -- openSUSE Feature: https://features.opensuse.org/307154
participants (1)
-
fate_noreply＠suse.de