Why Upgrade? Getting tired...

[tek_heretik]

Your question implies that you might not truly understand what we're discussing. We are considering how to continually change where installed binaries are coming from. Essentially, the method under investigation here results in a machine that always and only contains packages from whatever the current development version is. This in no way changes the definition of LTS or how an LTS-built machine will behave. If you have installed an LTS version, and you make no changes to your /etc/apt/sources.list file, then nothing that we're discussing here will affect you.

Ah, thank you, I'm breathing a huge sigh of relief.

[Snowhog]

My read of Kubicle's suggestion is that you can always stay "rolling" by having only the single repo line for whatever the current development pocket is. Right now, that's:

deb http://archive.ubuntu.com/ubuntu/ saucy main restricted universe multiverse

You could go super-bleeding-edge and add the proposed pocket:

deb http://archive.ubuntu.com/ubuntu/ saucy-proposed main restricted universe multiverse

Because all development takes place in these two pockets, you won't need anything else. The backports, security, and updates pockets start accumulating packages only after a release is finished and declared generally available.

In this interesting rolling model, you would actually not make any changes to your /etc/apt/sources.list until development opens for the next version. Once that happens, you will change the word saucy to whatever the name is for the next version and then perform a dist-upgrade.

This is a fascinating concept, one which I plan to try myself.

Okay. So, now, I have raring repos. I 'add' the one (or two) saucy repos and continue as "I" do, with regular dist-upgrades. At the time that saucy is released as 'final' -- no longer a release candidate -- I would change the one (or two) saucy repos to the next release code-name, and change my existing raring repos to saucy.

Do I have the concept down correctly?

[SteveRiley]

Okay. So, now, I have raring repos. I 'add' the one (or two) saucy repos and continue as "I" do, with regular dist-upgrades.

Remove all Raring entires now. Keep only the single line for the Saucy pocket. You could add the second line for the Saucy proposed pocket, which provides true bleeding edge; however, packages in proposed move into the standard pocket pretty quickly -- after certain rounds of testing have been done.

You should continue your daily dist-upgrades as this will keep your machine fresh.

At the time that saucy is released as 'final' -- no longer a release candidate -- I would change the one (or two) saucy repos to the next release code-name, and change my existing raring repos to saucy.

Your first phrase is correct: you would change the one (or two) Saucy lines to whatever T-Series is called. Your second phrase doesn't apply, since you will have already removed the "existing raring repos."

[Snowhog]

Okay. I'm gonna do it! (If you never hear from me again, please, remember me occasionally with fondness! )

[SteveRiley]

I'm gonna try the same thing in a VM, starting with Precise. Then to Quantal, Raring, and Saucy. Will report back here when I'm done.

[Snowhog]

The button has been pushed! I hope that I don't end up tearing a hole in the fabric of the Universe!!

[SteveRiley]

So far...

* Installed Precise into VirtualBox VM

* Modified /etc/apt/sources.list to be:

deb http://us.archive.ubuntu.com/ubuntu/ quantal main restricted universe multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ quantal main restricted universe multiverse

deb http://archive.canonical.com/ubuntu quantal partner
deb-src http://archive.canonical.com/ubuntu quantal partner

deb http://extras.ubuntu.com/ubuntu quantal main
deb-src http://extras.ubuntu.com/ubuntu quantal main

* dist-upgraded

* The installation successfully upgraded from Precise to Quantal. I am now performing the Quantal-to-Raring upgrade.

[tek_heretik]

Your question implies that you might not truly understand what we're discussing

You're right, I didn't quite get what you guys were/are up to (besides tearing holes in time/space continuum, lol), you guys are messing with the upgrade stream from your own machines, seeing what's possible without breaking an install, but for a second there it looked like you were contemplating a sweeping change from the Kubuntu end. A rolling bleeding edge and an LTS for the faint of heart (lol) is actually a good idea, it would probably save a lot of headaches and time all around. I have 4 spare HDDs sitting on a shelf, I should be testing different scenarios too (and reporting results) but between work and the gf making demands on my time...

[SteveRiley]

Having ubuntu set up a "devel" pointer to the current development version would remove the need to edit the repo when a version is released

Hey, Kubicle, looks like someone was reading your mind!



http://archive.ubuntu.com/ubuntu/dists/devel/
http://archive.ubuntu.com/ubuntu/dists/devel-proposed/

[SteveRiley]

Well, the experiment worked. My VM is now at Saucy. I had to dist-upgrade a second time once the Saucy upgrade finished, because APT's solver couldn't figure out how to handle an Amarok-related dependency during the Raring-to-Saucy conversion. The printer applet crashes on boot-up, and certain windows have an odd appearance -- I attribute the appearance issue to running in a VM.



Time to add saucy-proposed to see what might break, haha.

[tek_heretik]

Umm, excuse me for being a little green/dumb, first I should mention I've never ran a VM, so I wouldn't know if you can 'virtually reboot' it or not, why I am saying this is because some upgrades require a reboot, just a curious onlooker (your experiment has now become a spectator sport, lol).

[SteveRiley]

Yes, after each edit of /etc/apt/sources.list and dist-upgrade, I rebooted the virtual machine.

[SteveRiley]

Re-applying the Air desktop theme fixed the unusual appearance.

Iterating through apt-get --purge autoremove and apt-get purge $(deborphan) until both had nothing left to do fixed the printer applet problem. There were some left-over Python bits from earlier releases that apparently caused the applet to get confused.

[tek_heretik]

Re-applying the Air desktop theme fixed the unusual appearance.

Hah, funny you should mention that, I've done that myself several times, works like a charm.

[life0riley]

Umm, excuse me for being a little green/dumb, first I should mention I've never ran a VM, so I wouldn't know if you can 'virtually reboot' it or not, why I am saying this is because some upgrades require a reboot, just a curious onlooker (your experiment has now become a spectator sport, lol).

They are probably using VirtualBox to run a virtual instances of their system as a guest inside their host system. You could potentially run multiple OS's at the same time depending on your resources. The nice thing is you can do anything to the guest without changing anything on the host.

Here is a fresh install of a raring guest inside my precise host.