[opensuse-factory] Announcing Tumbleweed Snapshots: Rolling With You
From another angle, the capabilities of rollback using snapper and btrfs are widely advertised, but the cumbersome and rather unusable state in which a user is left is not commonly discussed. If for example a kernel and/or network manager update completely break network functionality for certain users they can rollback, but then what. As they wait for a fix their installation falls further behind and with that it becomes less and less likely that installing a new
Some of you may remember over a year ago when I proposed the concept of Tumbleweed Snapshots [1] and later the prototype that I provided [2]. Today I would like to announce hosting for the snapshots, that is not inside my house :), and ready to use! For those not familiar with the concept I will describe it in the form to which it has evolved. Tumbleweed, being a rolling distribution, is constantly changing and packages are constantly being rebuilt against one another and updating requirements. As such it becomes necessary to update even when undesirable. For example, one is running snapshot 17 and the next day snapshot 18 contains a QT update that rebuilt a large number of packages. When attempting to install an application that depends on QT one is greeted with an ugly unresolveable error. It is then necessary to run a full update, likely very large with many unrelated changes, in order to simply install an application as would have been possible yesterday. If a remote repository containing historical snapshots was available one could simply install the application and perhaps the handful of new dependencies it requires rather than having to update the entire system. This provides one with the benefits of a rolling distribution without requiring the constant change. A week later when a new kernel and DRM stack provides an exciting feature it is still easy to update everything and be running the latest code, but the user is not interrupted by having to update when it should not be necessary. package will function properly. On a similar note, if one wanted to install debuginfo packages it is many times impossible without first updating that application and with it many of its dependencies. All of these scenarios have occurred to either myself or friends or family. These problems of course do not exist in fixed releases like Leap, but the latter of course does not provide the latest sources. Tumbleweed Snapshots provides the best of both worlds, the latest packages when you want them and the one package you need in the middle of working on a project. If you are interested in trying out the snapshots just update to any snapshot past 20171120 like you would normally and then perform the following. zypper in tumbleweed-cli tumbleweed init During `init` the original repo files are kept and can be restored by: tumbleweed uninit If you are curious, run `zypper lr -U` before and after the init to see the URLs change. Originally, this was done via direct manipulation of the repo file, but was refactored to a libzypp config option [3] and later as vars.d/ by mlandres. The final implementation simply updates the text file /etc/zypp/vars.d/snapshotVersion after changing OSS and NON-OSS repo URLS to include the variable. The latest snapshot will always redirect to the standard mirror network until it is no longer the latest snapshot at which point it will be served directly. This means that when performing rollbacks via snapper or simply waiting a few days after updating the URL never needs to change and continues to work as expected. All zypper operations are unaffected except that the target snapshot needs to be changed in order to update, but that is made easy. tumbleweed switch or to switch, refresh, and dup tumbleweed update For full list of commands and options `tumbleweed --help` or see documentation [4]. A short video demonstration is also available [5]. Lastly, if there are mirror administrators interested in hosting/mirror the snapshots let me know. Using various tools for interacting with S3 it should be easy to make a copy of the public bucket. For those interested, take a look at the variations of the tool that creates the snapshots [6]. An aside, due to rsync.opensuse.org being regularly out-of-sync and not yet having access to stage.opensuse.org I am relying on up-to-date mirrors that have stage access and thus will be triggering the snapshots manually util that is resolved. As such the latest snapshot may not always redirect immediately. The reason for the delay was waiting for official hosting by openSUSE which has seen no tangible progress after a year. As such I decided to just move forward rather than needlessly delay this any longer. Depending on the interest it should clear what sort of costs will be incurred on AWS. I have further plans to provide more information about the snapshots and issues pertaining to them to aid users in knowing when to update so stay tuned. Enjoy! [1] https://lists.opensuse.org/opensuse-factory/2016-10/msg00591.html [2] https://lists.opensuse.org/opensuse-factory/2016-12/msg00025.html [3] https://github.com/openSUSE/libzypp/pull/68 [4] https://github.com/boombatower/tumbleweed-cli [5] https://www.youtube.com/watch?v=RkDwGiS9Kcc [6] https://github.com/boombatower/tumbleweed-snapshot -- Jimmy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 22/11/2017 23:52, Jimmy Berry ha scritto:
Some of you may remember over a year ago when I proposed the concept of Tumbleweed Snapshots [1] and later the prototype that I provided [2]. Today I would like to announce hosting for the snapshots, that is not inside my house :), and ready to use!
I like it but I'm not sure if is really usable for people with additional repo (Nvidia, Packman..). Anyway, good job, thanks. Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Nov 22, 2017 at 5:09 PM, Daniele <kailed@kailed.net> wrote:
I like it but I'm not sure if is really usable for people with additional repo (Nvidia, Packman..). Anyway, good job, thanks.
Those are certainly things I have considered, but merely depend on resources to host. As for packman I figured I would need to look into legal issues surrounding distribution for the same reason it is not part of OBS. Otherwise, I would expect it to take much less space than Tumbleweed proper. Similarly develop projects could be handled as well and even Nvidia if worked around re-distribution or local copy. With a few small tweaks to the tool folks could snapshot their devel project of choice and provide extra snapshot repos or ...official hosting if resources available. That said having the main repos snapshotted removes a large portion of the moving bits. Thanks, -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2017-11-22 at 16:52 -0600, Jimmy Berry wrote:
Some of you may remember over a year ago when I proposed the concept of Tumbleweed Snapshots [1] and later the prototype that I provided [2]. Today I would like to announce hosting for the snapshots, that is not inside my house :), and ready to use!
For those not familiar with the concept I will describe it in the form to which it has evolved.
Tumbleweed, being a rolling distribution, is constantly changing and packages are constantly being rebuilt against one another and updating requirements. As such it becomes necessary to update even when undesirable. For example, one is running snapshot 17 and the next day snapshot 18 contains a QT update that rebuilt a large number of packages. When attempting to install an application that depends on QT one is greeted with an ugly unresolveable error. It is then necessary to run a full update, likely very large with many unrelated changes, in order to simply install an application as would have been possible yesterday.
Certainly a nice helping solution, but keep in mind that bug reports coming from such a 'mix-and-mash' upgrdaed TW setup will simply not be handled. There have been numerous times reports about libraries that changed in incompatible ways without changing their soversion. Such things will bite you even more often. Let alone that a new library is perfecly allowed to add functions without changing the so-version. A binary built against the newer lib might make use of this new functions. The dependency will, nevertheless, be on libFOO<NUM>, with <NUM> not having changed, yet your application not starting in the end. Tumbleweed snapshots are a tested unit; the same trouble you keep on running in while running 'zypper up' instead of 'zypper dup' will bite you here. And I for one will always ask for 'zypper dup' on a bug if this setup is being used. Cheers Dominique
On Thu, 23 Nov 2017, Dominique Leuenberger / DimStar wrote:
On Wed, 2017-11-22 at 16:52 -0600, Jimmy Berry wrote:
Some of you may remember over a year ago when I proposed the concept of Tumbleweed Snapshots [1] and later the prototype that I provided [2]. Today I would like to announce hosting for the snapshots, that is not inside my house :), and ready to use!
For those not familiar with the concept I will describe it in the form to which it has evolved.
Tumbleweed, being a rolling distribution, is constantly changing and packages are constantly being rebuilt against one another and updating requirements. As such it becomes necessary to update even when undesirable. For example, one is running snapshot 17 and the next day snapshot 18 contains a QT update that rebuilt a large number of packages. When attempting to install an application that depends on QT one is greeted with an ugly unresolveable error. It is then necessary to run a full update, likely very large with many unrelated changes, in order to simply install an application as would have been possible yesterday.
Certainly a nice helping solution, but keep in mind that bug reports coming from such a 'mix-and-mash' upgrdaed TW setup will simply not be handled. There have been numerous times reports about libraries that changed in incompatible ways without changing their soversion. Such things will bite you even more often.
Let alone that a new library is perfecly allowed to add functions without changing the so-version. A binary built against the newer lib might make use of this new functions. The dependency will, nevertheless, be on libFOO<NUM>, with <NUM> not having changed, yet your application not starting in the end.
Tumbleweed snapshots are a tested unit; the same trouble you keep on running in while running 'zypper up' instead of 'zypper dup' will bite you here. And I for one will always ask for 'zypper dup' on a bug if this setup is being used.
But he's just trying to continue using an older snapshot, not a mix&mash as far as I understand. Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Nov 23 09:23 Dominique Leuenberger / DimStar wrote (excerpt):
On Wed, 2017-11-22 at 16:52 -0600, Jimmy Berry wrote:
For example, one is running snapshot 17 and the next day snapshot 18 contains a QT update that rebuilt a large number of packages. When attempting to install an application that depends on QT one is greeted with an ugly unresolveable error. It is then necessary to run a full update, likely very large with many unrelated changes, in order to simply install an application as would have been possible yesterday.
... ... a new library is perfecly allowed to add functions without changing the so-version. A binary built against the newer lib might make use of this new functions. The dependency will, nevertheless, be on libFOO<NUM>, with <NUM> not having changed, yet your application not starting in the end.
I don't see a real problem here. Assume a user is running snapshot 17 and the next day snapshot 18 contains a QT update and that new application gets re-built with a new function in libFOO<NUM>. Then installing that new application (and only it) into the outdated snapshot 17 will result that this new application (and only it) fails to start. No worries because it is obvious for the user that "something is wrong" with his new application (and only it). I think the crucial point is the "only it". As far as I understand it the basic idea behind is that changes and resulting issues are kept as local as possible. When that new application does not work within the outdated snapshot 17 nothing else became wrong. All what had worked in the outdated snapshot 17 still works. Now the user can decide if and when he will do a full system upgrade to a current snapshot 18 (or 19 or whatever later) to get that new application running. Regarding invalid bug reports because a user had installed whatever "new application" into his outdated system: We have to deal with such invalid bug reports since ever because some users did and do install whatever "latest greatest from wherever" into their systems. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Nov 23 2017, Johannes Meixner <jsmeix@suse.de> wrote:
Then installing that new application (and only it) into the outdated snapshot 17 will result that this new application (and only it) fails to start.
Note that due to lazy binding it can fail any time, even if it starts well. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Nov 23, 2017 at 2:23 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
Certainly a nice helping solution, but keep in mind that bug reports coming from such a 'mix-and-mash' upgrdaed TW setup will simply not be handled. There have been numerous times reports about libraries that changed in incompatible ways without changing their soversion. Such things will bite you even more often.
This introduces zero "mix-and-mash". If someone was using lots of repos before they still will, if not they still will not. SO versions have absolutely nothing to do with this and will not bite more frequently. Bug reports will be the same since still running the same Tumbleweed. If user reports from seven day old update it will be the same with this setup or the default.
Let alone that a new library is perfecly allowed to add functions without changing the so-version. A binary built against the newer lib might make use of this new functions. The dependency will, nevertheless, be on libFOO<NUM>, with <NUM> not having changed, yet your application not starting in the end.
Again, really not relevant at all.
Tumbleweed snapshots are a tested unit; the same trouble you keep on running in while running 'zypper up' instead of 'zypper dup' will bite you here. And I for one will always ask for 'zypper dup' on a bug if this setup is being used.
Zero change to zypper operation as I stated. Still expected to do a dup. Based on this and other emails it seems I need a more verbose explanation of what this attempts to accomplish and how. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Nov 24, 2017 at 4:51 PM, Jimmy Berry <jimmy@boombatower.com> wrote:
On Thu, Nov 23, 2017 at 2:23 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
Certainly a nice helping solution, but keep in mind that bug reports coming from such a 'mix-and-mash' upgrdaed TW setup will simply not be handled. There have been numerous times reports about libraries that changed in incompatible ways without changing their soversion. Such things will bite you even more often.
This introduces zero "mix-and-mash". If someone was using lots of repos before they still will, if not they still will not. SO versions have absolutely nothing to do with this and will not bite more frequently. Bug reports will be the same since still running the same Tumbleweed. If user reports from seven day old update it will be the same with this setup or the default.
If anything the default setup is mix in match since the remote repo is "rebased" regularly and does not match the local install. Given what you mention about SO versions you are likely to have trouble if not updating first. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 22 Nov 2017, Jimmy Berry wrote:
Some of you may remember over a year ago when I proposed the concept of Tumbleweed Snapshots [1] and later the prototype that I provided [2]. Today I would like to announce hosting for the snapshots, that is not inside my house :), and ready to use!
For those not familiar with the concept I will describe it in the form to which it has evolved.
Tumbleweed, being a rolling distribution, is constantly changing and packages are constantly being rebuilt against one another and updating requirements. As such it becomes necessary to update even when undesirable. For example, one is running snapshot 17 and the next day snapshot 18 contains a QT update that rebuilt a large number of packages. When attempting to install an application that depends on QT one is greeted with an ugly unresolveable error. It is then necessary to run a full update, likely very large with many unrelated changes, in order to simply install an application as would have been possible yesterday.
So the issue is that somebody (for example packagekit) does a refresh on the repo file and not that the mirrors purge old rpms referenced from older meta data, right? To me it sounds you want to "pin" metadata instead? What happens to security updates in this case? I suppose the way we organize repository meta-data is less than optimal here. With updated metadata I suppose you can't even do a zypper in glibc-2.22-4.9.1.x86_64 with a version from an earlier snapshot. That is, we'd need repo metadata that covers the full state of the download area, thus reflecting what you can actually install? And zypper having multiple version choices for a specific package could be asked to do a "minimal" install that requires the least number of packages to update but by default would prefer the newest version. Such repo data might be huge of course and we might be too aggressive in pruning old binary rpms from the download area and thus making old repodata invalid fast. Disclaimer: I didn't look into what you actually do implementation wise. Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Nov 23, 2017 at 3:15 AM, Richard Biener <rguenther@suse.de> wrote:
On Wed, 22 Nov 2017, Jimmy Berry wrote: So the issue is that somebody (for example packagekit) does a refresh on the repo file and not that the mirrors purge old rpms referenced from older meta data, right? To me it sounds you want to "pin" metadata instead? What happens to security updates in this case?
Pinning metadata is not terribly useful if the referenced rpms are not available in the remote repo. Security updates remain unchanged. The update repo (for urgent security fixes) is already iffy depending on which snapshot you have installed and it is not snapshotted in anyway by my tool. As such the behavior should be the same as default setup.
I suppose the way we organize repository meta-data is less than optimal here. With updated metadata I suppose you can't even do a zypper in glibc-2.22-4.9.1.x86_64 with a version from an earlier snapshot.
That is, we'd need repo metadata that covers the full state of the download area, thus reflecting what you can actually install? And zypper having multiple version choices for a specific package could be asked to do a "minimal" install that requires the least number of packages to update but by default would prefer the newest version.
Such repo data might be huge of course and we might be too aggressive in pruning old binary rpms from the download area and thus making old repodata invalid fast.
Indeed. Having to download such a large amount of meta data, depending on how far back is available just to see the current state seems rather suboptimal. Creating the "merged metadata" and then managing the rpms based on it does not seem beneficial. From the user stand point they simply want to install the new package that was built for their current install. If they want everything updated then they should update. This implementation preserves full meta data sets for each snapshot and keeps all the relevant rpms. As such you simply point the repo URL at the snapshot you have installed or want to install and zypper operates normally. The default setup (depending on what changes are in newer snapshots) is basically like running Leap 42.3 with your repos pointed at 15.0 and installing kate. That may or may not end well. The expected behavior there would be to dup to 15.0 and then install kate. Rather than expect that users dup every day this allows users to update at their own pace, but still install things as needed. Your idea about asking zypper to install with "minimal change" seems like a similar concept, but would require further investigation and implementation. This approach would appear simpler and operates transparently as if they are "mini-ephemeral-static distros" which are just historical Tumbleweed snapshots. Purely to allow a user to keep using the snapshot which they have installed since installing new packages essentially built for a "different" distro is less than ideal. Basically, users are in two modes: I want to update to latest, or I just want to install this new thing. This allows those mental modes to map to reality just like they did prior to rolling release. Depending on the way the rpm requirements are setup I've seen installing a new application trigger partial qt or kde updates that create an unusable desktop (even X fail to start). Short of some serious changes to spec file policies and tooling this seems like the only sane solution. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (6)
-
Andreas Schwab -
Daniele -
Dominique Leuenberger / DimStar -
Jimmy Berry -
Johannes Meixner -
Richard Biener