flat priorities

Greg KH recently advised to use flat priorities using openSUSE Tumbleweed.
I had used differentiated priorities until now. When changing to flat I get this vendor change (zypper -vv dup):

The following packages are going to change vendor:
gkeyfile-sharp  0.2-2.1 -> 0.2-3.1  obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE
gudev-sharp     0.2-2.1 -> 0.2-3.1  obs://build.opensuse.org/openSUSE:Tumbleweed -> openSUSE

These packages are used by Tumbleweed released banshee application. I ask myself, why Tumbleweed packages exist? This also applies to btrfsprogs package having a minor version than openSUSE-update repository.

I know btrfsprogs failed to build in the tumbleweed repo which is why it would switch, the others may be in a similar position.

@malcolmlewis, thanks for the info!

Shouldn’t Tumbleweed be a bit better secured against these failures? Why not just the other way round: Just give it a higher priority (using lower numbers)! Like we are used to with packmans Tumbleweed repository, because otherwise we get mixed proprietary binaries with opensource ones. It is not that much complicated to give priorities. But then Tumbleweed Maintainer(s) have to get informed when security related updates are on the agenda. Should this be discussed on factory mailinglist with Greg?

As indicated by Greg in another thread ( New packages in Tumbleweed - how do I get to know about them? - Page 3 ), leave them all the same priority…

This is actually a good question. The short answer is that Tumbleweed exists as a convenient compilation repo, it does not really have packages of it’s own but ones pushed to Tumbleweed when considered stable by the developers.

Now Greg is advising to use just 11.4 repos plus Tumbleweed, so a “zypper dup” can be used to upgrade to “highest” available version but also to occasionally back out packages which prove troublesome. The Tumbleweed repo has a different “Vendor” from standard openSUSE repos, which means just adding the repo & doing “zypper up” does not do what one might expect. Only newly installed packages would be sourced from the Tumbleweed repo.

The problem with this is that real users like Packman, especially the multi-media codec support, which suffers from software patent issues and would risk aggressive legal action if distributed by the distro in misguided jurisdictions. When Tumbleweed issues packages with higher versions than those in Packman (as they have) “zypper dup” unfortunately wants to change the vendor & upgrade to the latest non-Packman rpm’s missing end-user desired additional functionality ie play proprietary codecs.

Now I’ve actually been avoiding following Greg’s advice closely yet heeding it. What I have done is set things up so I use zypper up, prioritised the Packman multi-media repos in order to have “zypper dup” run as clean as possible, only some desire to downgrade linphone & a library due to kopete dependency. This method has Pro’s & Con’s :

  1. Less attention required on “zypper up”, no troublesome vendor changes away from Packman repo; less churn due to downgrading then re-installing Packman multimedia.
  2. Avoidance of “damage” due to mistakes like the inconsistent Factory KDE upgrade to 4.6.95 causing large unwanted downgrades back to openSUSE 11.4
  3. Manual switch to higher version of applications eg) gpg (which also required non obviously
    upgrade of libassun)

Tumbleweed actually uses the OBS “linking” feature where packages are published in a repo, that originate in another. This was shown up, when Tumbleweed distributed KDE 4.7 rc2 rpm’s which were not yet published in Factory, as they were being readied. The libassun business might have been prevented if the dependency of gpg-2 on the higher version library had been present in the rpm, then zypper’s solver ought to have refused the upgrade.

So for those who are happy with 11.4 plus Tumbleweed and want the latest versions, “zypper dup” is convenient. If you want Packman codecs it’s less so, with either additional follow up actions required after an update, or if you don’t follow Greg KH’s advise you need to run “zypper -v dup -D” periodically and understand what it’s telling you. In event of likely inconsistencies, a “zypper dup” followed up by switch to Packman package versions, would generally sought inconsistencies without requiring much skill, at cost of more downloading. I am avoiding that, but having to keep a watchful eye on updates and right now as Greg KH would say “I’m on my own” with no-longer distributed (but working) KDE packages until KDE 4.7 becomes “stable” (according to oS package developers).

Right now, Tumbleweed is most convenient for developers but rather a cobbled together experimental compromise for end users. The real question is whether this can be improved in the future, as the Tumbleweed repo has proven the advantages of the dynamic rolling distro model (getting fresher code with features & fixes sooner to end users before developers have moved on to new challenges), without too much of the serious issues predicted by advocates of the traditional “stable” release model.