[02:48] <agrestringere> hello, I'm looking to do some testing on 13.04 so I wanted to know the best way upgrade from 12.04 to the 13.04 daily build...
[02:53] <RAOF> agrestringere: You'll need to go through 12.10, but that'll be easy; that's just a do-release-upgrade away. I think you can also ‘sudo do-release-upgrade -d -p’ to get from 12.10 to raring, but if we haven't got that sorted out yet you can simply edit /etc/apt/sources.list and replace “quantal” with “raring”.
[02:54] <agrestringere> RAOF, okay thanks, is there a way to revert if things get really messed up?
[02:55] <RAOF> Downgrades are not supported; you can, however, try it in a sandbox by passing “--sandbox” to do-release-upgrade
[03:17] <bjsnider_> a downgrade would be a good thing to use a btrfs snapshot for
=== bjsnider_ is now known as bjsnider
[03:17] <RAOF> If you happened to be using btrfs, yeah, it's entirely safe.
[03:17] <RAOF> (Modulo btrfs bugs)
[03:18] <bjsnider> i was speaking more theoretically at this point
[03:18] <RAOF> Oh, it's implemented - check out apt-btrfs-snapshot.
[03:19] <bjsnider> yeah but i'm not sure people should be using btrfs yet. not convinced it's ready freddy
[03:20] <RAOF> It's actually _not_ 100% safe, because applications might change their configuration in non-forwards-compatible ways; it's not uncommon for at application to migrate to a new format on run, which would leave your data stranded if you roll back.
[03:20] <bjsnider> you'd have to back up /home too
[03:20] <bjsnider> certain aspects of it
[03:20] <RAOF> Right, and it becomes an essentially impossible project.
[03:21] <bjsnider> impossible?
[03:21] <RAOF> How do you tell if an application has moved something into a form that is unreadable by one of its previous versions?
[03:22] <bjsnider> well, you back up the key dirs, and then replace the upgraded ones upon downgrading
[03:22] <bjsnider> .local, .cache et al.
[03:23] <RAOF> So, now we're destroying work on rollback.
[03:23] <bjsnider> right, but i was also assuming the original question was the case
[03:23] <bjsnider> "do some testing"
[03:23] <bjsnider> not permanently upgrade
[03:24] <RAOF> Ah, so we've got different goals for ‘rollback’. Fair enough.
[03:24] <RAOF> In that case you'd just snapshot $HOME as well as /
[03:24] <bjsnider> i just interpreted that phrasing as being very temporary
[03:24] <RAOF> Make it very clear that going back will wipe your system back to the previous state.
[03:28] <bjsnider> i dunno why there isn't a dpkg-downgrade type thing
[03:29] <RAOF> Because of all these problems?
[03:30] <bjsnider> well, if the user wants to do this, it's their responsibility
[03:30] <RAOF> Having a dpkg-downgrade would suggest that you could downgrades are supported, which is quite different from "you can try this, and if it doesn't work you can throw away everything you've done after this point and go back”
[03:31] <RAOF> You obviously *can* downgrade packages - apt-get install foo=$OLD_VERSION will work as long as $OLD_VERSION is in the archive, and you can manually do it with dpkg and downloading from launchpad essentially as far back as you care to go.
[03:48] <ScottK> And if it breaks, you get to keep both halves..
[03:55] <agrestringere> okay, so how does the sandbox work?
[03:57] <agrestringere> I'll read the documentation, thanks for the info...
[03:57] <RAOF> agrestringere: It sets up an overlay filesystem, and makes all the changes on that overlay.
[03:58] <RAOF> So you can go back by throwing away the overlay, but if you want to keep it you should probably throw away the overlay and upgrade again without the sandbox.
[03:59] <agrestringere> that's what I'll do, I read that it installs root to temp, looks cool, I'll give it a shot
[04:04] <agrestringere> interesting view on rollbacks, it doesn't make sense that you can't rollback, I mean if upgrading is just a dpkg thing can't you store an entire history of actions and changes like you do in git and just "checkout 12.04.2"?
[04:09] <RAOF> That's what the btrfs discussion was. You certainly *can* do that, if you're willing to have your *entire* system rolled back to how it was when you installed 12.04.2. Including all of your personal data.
[04:09] <RAOF> That's not what people want from a rollback, though.
[04:09] <RAOF> And when you try to start implementing what people want, you run into all the funky edgecases.
[04:10] <agrestringere> seems like something only useful for server people because of uptime concerns
[04:11] <RAOF> Rollback?
[04:12] <RAOF> No, it'd totally be useful in a fairly wide range of circumstances if it were possible to implement well. :)
[04:15] <agrestringere> Complexity.
[04:28] <tjaalton> Sarvatt: great, thanks
[04:31] <agrestringere> have a good night, once again thanks for the instructions
[05:46] <mlankhorst> morning
[09:32] <xnox> RAOF: well there is apt-brtfsnapshot and by default we have @ and @home separate. So one can roll-back /system/ but not personal data, but there are all sorts of corner cases.
[09:32] <tjaalton> one could separate dotfiles from $home..
[09:33] <xnox> cause e.g. postgresql databases in /var/lib are _not_ system, but data yet again which shouldn't be rolle back.
=== yofel_ is now known as yofel