Mailinglist Archive: opensuse-factory (439 mails)

< Previous Next >
[opensuse-factory] Re: openSUSE Tumbleweed package management problem
  • From: Achim Gratz <Stromeko@xxxxxxxx>
  • Date: Sun, 09 Mar 2014 18:59:48 +0100
  • Message-id: <87ob1fckx7.fsf@Rainer.invalid>
Greg KH writes:
On Sun, Mar 09, 2014 at 11:11:04AM +0100, Achim Gratz wrote:
Greg KH writes:
That's because all of the Tumbleweed repo just rebuild due to KDE
updates, as well as other core updates (kmod and util-linux).

The kernel should either a) never rebuild

It rebuilds when a new kernel update happens, or a dependency of the
kernel packages are updated. What is wrong with that?

Nothing, if one of the other points is getting fixed. On the other hand
I can't see anything changing that would invalidate the existing kernel

or b) the version number needs to change with each rebuild

It does.

Specifically, the build number is incremented, not the version (which
really hasn't changed, so there's probably nothing to do here).

or c) all tools making use of the version number need to recognize
that a rebuild of the kernel actually overwrites any earlier builds of
the same version kernel so the old build is no longer available or

I don't understand what you mean by this.

If you install all those rebuilds on a kernel multiversion enabled
system and query for installed packages, you will see that the package
system thinks that all combinations of <version>.<buildnumber> are still
installed (look at the zypper output earlier to this thread). But only
the latest build of each version that you installed is actually present
on the system – the files for each build do not actually coexist, since
they are overwritten when the new build gets installed. This confuses
the hell out of the script that tries to delete old kernels for instance
and makes it delete kernel versions that you are actively trying to
keep. You can actually zypper rm the old builds without causing damage
(but that is a scary thing to do since you can't really tell that it's
not removing the current kernel).

d) the kernel installation needs to include the build number so that
multiple builds of the same versions can coexist on disk.

It should do that today.

No it doesn't, otherwise there'd be a ".2" right after the "-18" in the
following path on my system: /lib/modules/3.13.5-18.gbb654e2-pae

As I understand, each package that enables multiversion coexistence must
either use an installation path that does include the build number, must
never rebuild or must be cleaning up after itself when the install of a
rebuilt package overwrites an earlier one. Including the build number
is not appropriate for kernels as you almost assuredly want to keep a
number of previous versions and not builds of the same version.

I don't understand the problem here, everything works fine on my

Do you use a multiversion enabled kernel or not? If not, it is easy to
see why you never encounter the problem since it never presents itself.
If yes, then I don't understand why that problem isn't obvious to you.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups