New packages in Tumbleweed - how do I get to know about them?

As posted in other threads, there e.g. currently was an update in Tumbleweed concerning gpg packages, which rendered the system unusable as long as a newer libassuan was not updated at the same time.

This lead me to a problem I have with Tumbleweed (would probably be the same with other repos, too): Quite some time ago, I added the Tumbleweed repo, adjusted the priorities of the repos, and “switched system repositories” to Tumbleweed. This is fine for all packages which already were in Tumbleweed at this time, which are now used and updated in their Tumbleweed variant.

But now, more and more packages are getting into Tumbleweed which I up to now used in their 11.4 incarnation, e.g. the above given libassuan. YaST currently does not even inform me if Tumbleweed contains a new package which updates a package I still use in the 11.4-version. De facto I always have to manually check the Tumbleweed repo, whether there is some new package in it.

Am I missing something? How can I tell YaST to simply prefer any package in Tumbleweed as soon as it appears in there?

I don’t think you are missing anything. Some of us do not want to do that. Even though I use tumbleweed, I don’t want to be nagged everytime there is a Tumbleweed update.

If I want the latest version of an app, then I will look in the Tumbleweed repository to see if it is there. Or if I am simply curious as to what is available in Tumbleweed then I will look in QT version of YasT > Software > Software Management and select the Tumbleweed repository, and I will get a wonderful colour indication as to what updates are available for Tumbleweed.

I do NOT want to be nagged each and everytime there is some cutting edge update to an app that I don’t care about.

Each to their own, I guess.

For me the idea of Tumbleweed was getting the latest, but rather tested, packages, without going through every single build service repo.

If I’d like to only hunt down specific single apps, I can simply add the relevant repos in the build service. But if I tell YaST that Tumbleweed is my preferred source of packages (high priority, “switch system packages” and so on), I rather expect YaST to use a Tumbleweed version if something new is in there.

IMHO, the example gpg/libassuan is the best example why this would make sense from the consistency point of view, too. There are too many dependencies between packages if you have to manually check it.

I can do that too. But typically before a factory app goes into Tumbleweed there is an extra vetting process which means Tumbleweed apps tend to be more stable than factory.

Ergo, I prefer Tumbleweed.

I’m a strong believer in if ain’t broke, don’t fix it. And I venture one obtains very little from 95% of the Tumbleweed updates. One can obtain over 1GB a month of update from Tumbleweed, for what return in functionality ?

I much prefer to pick and choose. Maybe once every 4 to 8 weeks I will update from Tumbleweed and I don’t need a reminder for that.

@Larx, I didn’t notice what DE you use for Tumbleweed. KDE and Gnome have their respective updater applets. I tend to use those to be notified of new updates, but I use either YaST Software Management or “zypper dup” to review potential changes before deciding which method to use for installing the updates.

Sometimes I use the distribution upgrade (zypper dup), other times I use YaST’s Online Update (for 11.4 updates) and Software Management (repo by repo) for example with packman-tumbleweed. On occasion I will pick-and-mix by application e.g for a tumbleweed kernel upgrade which I will update separately before anything else. So far, zero failures on Tumbleweed. :slight_smile:

I use the KDE update applet or the YaST2 software management. But both ways won’t inform you when a package which you have installed from openSUSE OSS or the respective update repository appears in a newer version in Tumbleweed.

Which leads to situations as with the gpg/libassuan-stuff as described in recent posts here: gpg is updated because it has been in Tumbleweed already, libassuan is not updated because up to now the version from the original 11.4 repo was sufficient. This results in a system you can no longer log in, which seems quite awkward to me. If YaST had recognized “oh, there’s a newer version of that library from Tumbleweed, which is the repository with the highest priority, so I’ll propose to update that,too”, the problem would never have occured.

Stuff like that is difficult to handle even if you cross check every single package you’re about to update.

BTW, if your philospophy is “if it ain’t broke, don’t fix it”, why then Tumbleweed at all :slight_smile: ?

On 05.08.2011 19:26, Larx wrote:
>
> I use the KDE update applet or the YaST2 software management. But both
> ways won’t inform you when a package which you have installed from
> openSUSE OSS or the respective update repository appears in a newer
> version in Tumbleweed.
>
> Which leads to situations as with the gpg/libassuan-stuff as described
> in recent posts here: gpg is updated because it has been in Tumbleweed
> already, libassuan is not updated because up to now the version from the
> original 11.4 repo was sufficient. This results in a system you can no
> longer log in, which seems quite awkward to me. If YaST had recognized
> “oh, there’s a newer version of that library from Tumbleweed, which is
> the repository with the highest priority, so I’ll propose to update
> that,too”, the problem would never have occured.
>
> Stuff like that is difficult to handle even if you cross check every
> single package you’re about to update.
>
> BTW, if your philospophy is “if it ain’t broke, don’t fix it”, why then
> Tumbleweed at all :slight_smile: ?
>
>

Since the assuan case I’ve investigated with vm and snapshots (aren’t
they great) and found that
If I go YaST > SW Management > View Repositories >Tumbleweed

and then “Switch System Packages to the versions in this repository”
libassuan gets updated.

I think I’ve done that before but I guess it does not harm to do it
always before tumbleweed updates.

OTOH I’ve kept a couple of older kernels, to make sure I can boot.
Here’s a link to that, watch line wraps:

http://lizards.opensuse.org/2011/07/14/improved-kernel-package-retention-in-12-1/

It seems that often I need to first remove the older kernels before all
updates can be performed.

Vahis

http://waxborg.servepics.com
openSUSE 11.2 (x86_64) 2.6.31.14-0.8-default “Evergreen” main host
openSUSE 11.4 (x86_64) 2.6.37.6-0.7-desktop in VirtualBox
openSUSE 11.4 (i586) 3.0.0-39-desktop “Tumbleweed” in EeePC 900

I use the QT version of YaST in Tumbleweed (on LXDE) and it DOES inform when a package installed from openSUSE OSS or the respective update repository appears in a newer version in Tumbleweed. It does.

And last I looked KDE had a QT version of YaST.

I use the QT version of YaST in Tumbleweed (on LXDE) and it DOES inform when a package installed from openSUSE OSS or the respective update repository appears in a newer version in Tumbleweed. It does.

As the poster before said: It does this, yes, but only for all the packages that were in Tumbleweed the last time you did a “switch system packages to this repo”. Any package which has its first appearance in Tumbleweed after this moment is quietly ignored. This is definitely the case because I routinely scan the Tumbleweed repo in order to manually switch packages to their Tumbleweed-versions.

If you have several repos activated (e.g. Packman and Packman Tumbleweed), you always get your system messed up if you do a “switch system packages to this repo” on Tumbleweed in order not to miss new packages.

No you do not get your repos mixed up with only those two extra.

Simply
(1) go to tumbleweed repos in YaST Software management, … switch system packages to this repos. Do NOT install . OK … Just have a few seconds patience.
(2) then go to packman repos in YaST Software management, … switch system packages to this repos. Do not install. Ok … Just have a few seconds patience.
(3) go to view > installation summary. Assess the update. Do you want it ? … No ? Then exit yast software management. Yes? Then update.

PLUS you have CHANGED the scope of the discussion. First it was about ONLY Tumbleweed for OSS/non-OSS/Update. Now you have thrown in Packman for Tumbleweed. What next ?

Where’s the problem in giving an example? I must admit I don’t quite understand your negative attitude towards my postings.

Hmmm … rather I see it as your negative attitude toward my views.

Did you check out the method in which I explained as to how you can get the list you want ?

If the priorities are set to correctly differentiate the repos, running “zypper dup” should take care of that situation i.e libassuan should be updated from Tumbleweed. Running “zypper dup” will present you with the upgrade plan in detail, so you can review and choose to proceed with it or abort. For Tumbleweed, according to the announcement, “zypper dup” was the intended method for upgrades from time to time.

BTW, if your philospophy is “if it ain’t broke, don’t fix it”, why then Tumbleweed at all :slight_smile: ?

Don’t know where that came from, and BTW it’s a bit silly here.

I confess I tried (perhaps not completely successfully) to ignore that reply “why tumbleweed at all”.

Hopefully we have shown the OP how to get the list they want, even if it does involve more manual process and more mouse clicks than what they may want.

I’m currently, on a Sandbox PC, testing Tumbleweed-11.4, for two reasons:

  • to see if its viable for me to eventually adopt as a more permanent repos on my main openSUSE PC (for only occasional updates)
  • to provide my own view/perspective, some support, and I hope some clarity on what I see as this great new repository for openSUSE

Thus far, when it comes to using Tumbleweed on more than just a Sandbox PC, my view is:

  • If it ain’t broke, don’t fix it
  • If i must get an update that is NOT available in ‘Update’ repos (for either features or because the OSS/Update is broken for my purposes and no Update fix is coming) then Tumbleweed is where I go
  • I prefer Tumbleweed over factory as there is a vetting process before any Factory package is put in Tumbleweed. Case in Point, Mesa 7.11 is available in Factory but has NOT been put into Tumbleweed, for good reasons …
  • Tumbleweed is constantly updating, meaning to stay constantly current is a MASSIVE download consuming enormous bandwidth
  • It IS
    possible to get a list of what IS in Tumbleweed in seconds (doing so manually every week or two or every month) and deciding then if one wishes to update

Now having stated that, there IS a place for those who want to update ALL the time, as they provide a level of testing that the rest of us can take advantage of. There are MANY cases of rolling back a version in Tumbleweed thus far, and those testers on the cutting edge DO provide a great service there.

And just to balance the above, I DO have a sandbox PC where I typically apply ALL Tumbleweed updates every 2nd week or so, and I thus I also support the Tumbleweed testing of ALL packages. But note that is a Sandbox PC, and not my main PC.

There’s much mention in this thread of using the qt yast tool “switch system packages to the versions in this repository”. Using this tool is perfectly valid, but outside the routine use parameters for Tumbleweed. So if you want to use it, you need to really know what you’re doing. The same goes for adding left-field repositories, perfectly valid, but for users who really know what they’re doing. And ditto for adjusting repository priories.

All variants outside the normal use/update protocols for Tumbleweed, like the ones above, need to be used with caution. I use some of them too, but they’re really for geeks, not for routine users.

I conclude for myself:

  • Usage case: Giving Tumbleweed high priority and “switch all system packages to this repo” with YaST software management
  • Expected behaviour: From now on all packages which are in Tumbleweed and have a higher version than installed packages are automatically updated in YaST
  • In fact: Only those packages which where in Tumbleweed at the time one “switched the system packages” are continually updated from Tumbleweed. All other, newer, packages at first have to be manually updated to the new Tumbleweed version.

I guess that’s not a Tumbleweed problem, but stems from the design of YaST software management. I made the mistake that I thought the Tumbleweed repo I added to my list will be handled like a “normal” openSUSE 11.4 update repo. This is obviously not the case, probably because of different vendors openSUSE 11.4 <-> Tumbleweed.
So you either have to run “switch system packages to this repo” regularly (with the problems given above) in order to be sure that all packages are up-to-date, or you have to browse through the Tumbleweed repo manually in order to find newly added rpms.
Not doing this regularly obviously can lead to a inconsistent system.

Is this conclusion correct?****

I do not believe that you will get an inconsistent system, but I believe the rest of what you posted could be accurate.

I have one PC (my rather ancient sandbox PC) running Tumbleweed-11.4 and also I have access to an equally ancient laptop PC (from our office Linux User Group) which is currently running Tumbeweed-11.4.

On my Sandbox PC, typically I update Tumbleweed-11.4 once every one or two weeks (sometimes longer, sometimes less).

On our Linux User Group laptop, typically I update Tumbleweed-11.4 once every 5 to 7 weeks.

Possibly my sample is too small, but I have yet to notice any inconsistencies. I have to confess both computers are running re-markedly well, despite my stated dislike for the approach that I am adopting on them. I note that most of the time I am not selecting to “switch the system package” on these PCs, although sometimes I do do that. My approach is inconsistent here, and I concede that inconsistency is not a good approach to follow for testing - I need to think as to what approach I should really follow for testing. But it does suggest to me that the approach that I don’t like (of updating all Tumbleweed with or without continual “switch the system package” appears to work better than my “if it ain’t broke don’t fix” conservative approach would support). So good on ya for succeeding here.

I do note that I have observed many roll backs in Tumbleweed, which I have dutifully applied when observed.

I do think that while we need users who do complete “switch the system package” updates (for testing), there is still an element of risk, as while Tumbleweed in my view is more stable than factory, it is also not as stable as the nominal openSUSE release.

Anyway, I’m glad that dispite different view points, I think some of the technical nuances of using YaST with Tumbleweed are a bit more understood by such discussions.

I just today ran across a situation where some updates were put in opensuse11.4-updates. That stimulated a switch of some packages in Tumbleweed repo to the updated packages in opensuse-updates. This was quite correct, intended by the maintainers. But the user in question didn’t get the updates because the priority of Tumbleweed repo was set higher (to 98).

Hi
But why the updates? You need to check the changelogs and satisfy
yourself that they do need to be updated. If you have an issue and raise
a bug and the tumbleweed maintainers see you have a later version you
may need to remove and reproduce the bug…

Maybe it’s just a matter of being patient as things are moving slow on
OBS with publishing at the moment. Tumbleweed updates may
have been pushed and built but not published to the repository yet, you
would need to check on the OBS project pages.


Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.7-desktop
up 3 days 20:58, 3 users, load average: 0.17, 0.08, 0.10
GPU GeForce 8600 GTS Silent - Driver Version: 280.13

Case in point btrfsprogs has failed to build on Tumbleweed and needs to
be corrected, built and published then you would not require
switching vendors…


Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.7-desktop
up 3 days 21:22, 3 users, load average: 0.05, 0.08, 0.11
GPU GeForce 8600 GTS Silent - Driver Version: 280.13