Tumbleweed package release numbers vs. build dates

I am using Tumbleweed without problems. Thank you for that. However, I have ended up using it in a not recommended and unsupported way.
I am confused due to the following: When there is a package available both in Tumbleweed repo and in current repo, zypper often prefers the package in the current repo because it has a higher release number though the package in Tumbleweed repo has a later build date.

I picked below as an example the package kdebase-runtime-branding.
In current there are packages for KDE 4.11 while in Tumbleweed there are KDE 4.12 packages. Now zypper dup prefers the branding package from current repo which is probably tailored for KDE 4.11 and thus may even prevent installing some KDE 4.12 packages.

The difference in build dates may be months. My intuition (based on no understanding on how Linux distributions are maintained) tells me to prefer the packages built lately for the latest Tumbleweed versions of kernel, kde and other software.

I ended up setting Tumbleweed priority to 95 while current repos have priority 99. I also have packman repos, libreoffice and some others and the few applications I use work ok. However, there is the risk that an important update is made in the current_updates but not in Tumbleweed repo. And I guess there are other risks.

My question is: What I do not understand about release numbers and build dates ?-)

(I have read the postings from last few years about Tumbleweed and repository priorities without finding an answer.)

|kdebase4-runtime-branding-openSUSE - The KDE Runtime Components|
|---|




||Alternate Version|Installed Version|
|---|---|---|
|Version:|13.1-6.9.11|13.1-2.5|
|Build Time:|pe 24. tammikuuta 2014 21.05.42|ti 18. helmikuuta 2014 17.37.30|
|Install Time:||ke 19. helmikuuta 2014 08.59.18|
|Package Group:|System/GUI/KDE|System/GUI/KDE|
|License:|GPL-2.0+|GPL-2.0+|
|Installed Size:|839,6 KiB|839,6 KiB|
|Download Size:|740,6 KiB|0 B|
|Distribution:||openSUSE:Tumbleweed|
|Vendor:|openSUSE|obs://build.opensuse.org/openSUSE:Tumbleweed|
|Packager:|http://bugs.opensuse.org||
|Architecture:|x86_64|x86_64|
|Build Host:|||
|URL:|http://www.opensuse.org/|http://www.opensuse.org/|
|Source Package:|kdebase4-openSUSE-13.1-6.9.11|kdebase4-openSUSE-13.1-2.5|
|Media No.:|0|0|
|Authors:|||



You should not compare the minor release numbers (coming after the “-”) across repos. They are repo-specific. So for example, a package with a new release number going into a repo for the first time could acquire a lower minor release number compared to the same package in another repo.

Ref your example, I also have the 13.1-2.5 package installed via zypper dup, as it is the newer build (at 18 Feb, versus 24 Jan for 13.1-6.9.11) even though it has the lower minor number. :wink:

My “current” repos and Tumbleweed repo are at the same default priorities, as recommended.

Well, as you consused wrote, the minor number (and the date of course) is repo-specific.

And there has been absolutely no change in kdebase4-runtime-branding-openSUSE since Oct. 4th (except for some packaging/versioning things).

Just download the tarball from Welcome - openSUSE Build Service (Tumbleweed) and Show openSUSE:13.1:Update / kdebase4-openSUSE - openSUSE Build Service (openSUSE:13.1:Update) and compare, if you want to verify that yourself.

So it doesn’t really matter which version you install.
Just take the one “zypper dup” offers you… :wink:

I also have understood that the minor release numbers are repo specific and should be ignored. However, I have got the impression that zypper dup relies on them rather than build dates. A continuation question is, do the build dates mean anything?For example, if I have two packages with same version number (major release number), the other build in September for openSUSE 13.1 and the other build yesterday for Tumbleweed does it matter, which one gets installed?I ask, because if I set all the repositories to equal priority, zypper dup ignores most of the packages from the Tumbleweed repo. I guess I do not properly understand what “building against” means.

I also have the understanding, that as long as the version numbers (major release number before the “-”) are equal, the source code is equal. However, it seems that the requirements for the packages may be different which may affect, what zypper dup does.

I guess I have to do more homework on how Linux distributions are build. Suggestions for good reading?

|kdebase4-runtime-branding-openSUSE - The KDE Runtime Components|
|---|




||Alternate Version|Installed Version|
|---|---|---|
|Version:|13.1-6.9.11|13.1-2.6|
|Provides:|kdebase4-runtime-branding = 4.11
kdebase4-runtime-branding-openSUSE = 13.1-6.9.11
kdebase4-runtime-branding-openSUSE(x86-64) = 13.1-6.9.11|kdebase4-runtime-branding = 4.12
kdebase4-runtime-branding-openSUSE = 13.1-2.6
kdebase4-runtime-branding-openSUSE(x86-64) = 13.1-2.6|
|Prerequires:|coreutils
grep
diffutils
fillup|coreutils
grep
diffutils
fillup|
|Requires:|libqt4-x11 >= 4.8.1
kdebase4-runtime >= 4.11
coreutils
grep
diffutils
fillup|rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsLzma) <= 4.4.6-1
libqt4-x11 >= 4.8.1
kdebase4-runtime >= 4.12
coreutils
grep
diffutils
fillup|
|Conflicts:|namespace:otherproviders(kdebase4-runtime-branding)|namespace:otherproviders(kdebase4-runtime-branding)|
|Supplements:|kdebase4-runtime & branding-openSUSE|kdebase4-runtime & branding-openSUSE|



If I set the priorities equal, I get the the package with older build date (with higher revision number) Is there something wrong in my zypper configuration?

Yes, zypper doesn’t care about the build time. It only respects the version numbers, and if they are equal the build numbers (i.e. the part after the ‘-’).

Those two packages don’t really have different requirements either.
The only difference is just that one needs “kdebase4-runtime>=4.12” and the other one “kdebase4-runtime>=4.11” (because it is built against KDE 4.11), but that’s of course also satisfied by KDE 4.12.

So don’t think too much about that I’d say, just use “zypper dup” and Tumbleweed like it’s intended to be used.

Not really “wrong”, but I suspect it could be due to some difference in persisted data wrt libzypp’s so-called database or zypper’s cache. The only evidence for that view is:

  • You changed repo priorities whereas I haven’t throughout a 12.3 based Tw –> 13.1 based Tw (zypper dup always since clean 12.3 install).
  • A possible outcome of using “zypper dup --from” (ref @Knurpht in a previous Tw thread) just once, where Apper’s behaviour (PackageKit equivalent of “zypper up”) is modified wrt notifying or not, a standard kernel update from Oss Update repo. I haven’t verified/failed this yet on my own system where I have the issue, when using Apper as a convenient heads up.

Since neither are recommended by Greg K-H for Tumbleweed, although I would like to understand the reason for the anomalies, I agree with wolfi here

So don’t think too much about that I’d say, just use “zypper dup” and Tumbleweed like it’s intended to be used.

because on the balance of probability it won’t be solved for Tumbleweed alone.

???
Again, there’s absolutely nothing wrong here.
zypper doesn’t care about any build date.
If the priorities of the repos are equal, it takes the package with the higher version number, if they are equal it takes the one with the higher build number.
That’s how it is designed.

Since neither are recommended by Greg K-H for Tumbleweed, although I would like to understand the reason for the anomalies,

Maybe I’m missing something here, but I don’t see any anomalies at all.

“zypper dup” installs the packages with the higher version/build number, and those come from Current repo in this case of the KDE branding packages.
To change this they would have to get a higher version number in Tumbleweed.

But it doesn’t matter for those branding packages, since they are exactly the same anyway, despite the build number (except for that minor difference in the dependencies, which doesn’t matter either because 4.12 is greater as 4.11 as well, so there’s no problem in installing the 13.1 package in Tumbleweed. It wouldn’t work the other way round though, the Tumbleweed package cannot be installed on 13.1 because it needs KDE >= 4.12 whereas 13.1 only has 4.11.5).

The KDE packages’ dependencies have been set in a way that this gives no problems whatsoever. Again, as you can see f.e. kdebase4-workspace-branding-openSUSE from the Current repo requires KDE >= 4.11 (not KDE == 4.11.x), and it is similar with the other branding packages.
This is even necessary now, because kdebase4-workspace stays at 4.11.x while the rest of KDE is at 4.12.x.

In my understanding it is not because of the build dates but because kdebase4-runtime-4.12 and some other KDE 4.12 packages require kdebase4-runtime-branding-4.12 which is provided by Tumbleweed (13.1-2.5) but not by openSUSE current (13.1-6.9.11)

Because zypper wants to install KDE 4.12 packages (= higher version number) it has to install 13.1-2.5 branding.


|kdebase4-runtime-branding-openSUSE - The KDE Runtime Components
|
|




||Alternate Version
|---|
|Installed Version
|
|Version:
|13.1-6.9.11
|13.1-2.6
|
|Provides:
|kdebase4-runtime-branding = 4.11
kdebase4-runtime-branding-openSUSE = 13.1-6.9.11
kdebase4-runtime-branding-openSUSE(x86-64) = 13.1-6.9.11
|kdebase4-runtime-branding = 4.12
kdebase4-runtime-branding-openSUSE = 13.1-2.6
kdebase4-runtime-branding-openSUSE(x86-64) = 13.1-2.6
|
|Prerequires:
|coreutils
grep
diffutils
fillup
|coreutils
grep
diffutils
fillup
|
|Requires:
|libqt4-x11 >= 4.8.1
kdebase4-runtime >= 4.11
coreutils
grep
diffutils
fillup
|rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsLzma) <= 4.4.6-1
libqt4-x11 >= 4.8.1
kdebase4-runtime >= 4.12
coreutils
grep
diffutils
fillup
|
|Conflicts:
|namespace:otherproviders(kdebase4-runtime-branding)
|namespace:otherproviders(kdebase4-runtime-branding)
|
|Supplements:
|kdebase4-runtime & branding-openSUSE
|kdebase4-runtime & branding-openSUSE


|



That’s correct, yes.
kdebase4-runtime-4.12.x requires kdebase4-runtime-branding-4.12, which is only available in Tumbleweed of course (13.1/Current ships 4.11).

But as I said, kdebase4-workspace is only available as 4.11.6 even in Tumbleweed (because KDE didn’t and won’t release a 4.12 version of this), and this of course needs kdebase4-workspace-branding-4.11 which is available from both Tumbleweed and 13.1/Current. And once again, it doesn’t matter which of the two versions you install, as they are exactly the same.
The same is true with kdm and kdm-branding since that stems from kdebase4-workspace as well and therefore also stays at 4.11.x.

All so true. I am afraid I confused some others but myself I am now less confused. Thank you.

I set all the repositories to equal priority. zypper dup reverted about one hundred packages from Tumbleweed to openSUSE 13.1, but now I am convinced that it is OK. One package was upgraded from a Tumbleweed revision built yesterday to an openSUSE 13.1. revision built in mid-October but as it is the same version, it must be OK. At least at the first glance everything is ok.

When one experiments alone with only superficial understanding one easily gets all kinds of stupid ideas how things work.


“It ain’t what you don’t know that gets you in trouble. It’s what you know for sure that just ain’t so.” (Mark Twain)

Ok, ignoring build date, then:

If the priorities of the repos are equal, it takes the package with the higher version number, if they are equal it takes the one with the higher build number.
That’s how it is designed.

In that case of equal priorities, mine installed “13.1-2.5”, whereas stated in post #7 @hvalisuo installed “13.1-6.9.11” AFAICT, that is an anomaly. Which one breaks your rule? where version = 13.1 in both cases.

Maybe I’m missing something here, but I don’t see any anomalies at all.

“zypper dup” installs the packages with the higher version/build number, and those come from Current repo in this case of the KDE branding packages.
To change this they would have to get a higher version number in Tumbleweed.

Again, if installed which one breaks the rule, from Tumbleweed “13.1-2.5” or from standard Update “13.1-6.9.11”?

Actually post #7 says that installed version is 13.1-2.5.
And at that time I had Tumbleweed priority higher than 13.1.
And as explained above, due to KDE 4.12 package requirements zypper dup installs the Tumbleweed version 13.1-2.5.

From now on I will follow the rule: Ignore the revision numbers after “-”, ignore the build dates and do not care whether the packages come from Tumbleweed or from current. Start worrying only if the version numbers (the number before “-”) show that the latest versions do not get installed.
In my understanding the advice in the Tumbleweed portal imply exactly this, but … Well we humans aren’t computers who follow good advice just like that.


“It ain’t what you don’t know that gets you in trouble. It’s what you know for sure that just ain’t so.” (Mark Twain)

Thanks for replying to clear up any misunderstanding. Sorry, your #7 doesn’t say that to me, it stated:

If I set the priorities equal, I get the the package with older build date (with higher revision number) Is there something wrong in my zypper configuration?

Since the “older build date” of 24 Jan refers to 13.1-6.9.11 (and looks like higher revision number), to be clear, you now seem to be saying there was simply a mistake in your post about the state of repo priorities.

And as explained above, due to KDE 4.12 package requirements zypper dup installs the Tumbleweed version 13.1-2.5.

Yes, and I know zypper has to resolve the dependency chains to the best of its ability. It has definitely improved over the years. The occasional anomaly might appear, but in this case my concern was based on post #7 pointing to different behaviour in our two Tumbleweeds.

In my understanding the advice in the Tumbleweed portal imply exactly this, but … Well we humans aren’t computers who follow good advice just like that.

:D. I always used to run Packman repo at a higher priority (lower number) to preserve multimedia quality, but not since 12.3-based and without any issues occurring.

My mistake. Sorry.
I set the priorities equal and about one hundred packages were reverted to “older build date” which had a higher revision number in “current”. However, exactly the branding package I had used as an example did not revert, because of KDE 4.12 dependencies.

Thanks for taking the time to confirm and clear that up.

Similar questions, including KDE versions, even from devs using Tw with different additional repo priorities from time to time, have exercised the Factory ml this year. They get exactly the same advice/support we get i.e. don’t do it. :slight_smile:

Yes, and another hefty update very recently of 90+ updated packages applied here, many of them KDE. I haven’t seen any real packaging issues here this year so far. I believe the number of Tw maintainers increased by at least one, since last year.