It would appear that on Apr 8, Isaac Dupree did say:
> On 04/08/10 07:21, Joe(theWordy)Philbrook wrote:
> > My take on it is that while it's always a good idea to be using a
> > current install medium, with Arch it only matters that your system is
> > able to become current via update. The release of a new install set in
> > itself should never be a reason to reinstall a working system.
>
> Good description (although I'm willing to bet there's some little bit of
> unimportant cruft on a system originally installed several years ago, due to
> various organizational updates, in addition to you as admin forgetting which
> files you've left around in /etc...)
No doubt. But cleaning out a build up of "cruft" on ones own system is a
separate thing from needing to reinstall simply because somebody released
a new install image... Though I'll acknowledge, that if I felt my system
was due for that intense a "spring" cleaning, I think I'd probably time
it to right after a new install set has been "sprung" on us... ;-7
> > All I know for sure is that while Arch takes a bit more work to get a
> > running desktop system than some other distros, The idea of not having
> > to start from scratch every 6 months makes it "way worth it..."
>
> if you don't mind running old versions of software... which I do...
I take it that you don't feel that "pacman -Syu" or if applicable
something like "yaourt -Syu –aur" Will bring your Arch system as fully
up to date as installing the latest Ubuntu release, followed by an
apt-get dist-upgrade would???
As a dedicated multi-Linux, multi-booter I usually have three or more
distros installed. I've noticed enough variance in "software
versions" between fresh installs of the "latest" OS releases of enough
distros to know that a new install of a new OS release is no guarantee
that *_ALL_* of the software will be the latest possible release.
> > I've learned that if I can only find the right wiki entry, there is
> > usually a good comprehensive walk through of whatever I need to do to my
> > system. And this way, I wind up with a better understanding of my system.
> oh indeed! Over the years, the Gentoo wiki has been a pretty good source of
> info too (whatever distro you're on), and even the Ubuntu wiki has some nice
> info for specific hardware (MacBooks at least), etc. Arch has a pretty good
> wiki now also!
I'll agree that there's good stuff in the other wiki(s). But the Arch
wiki impressed me with how it approaches how-to instructions with
regard to helping users who really don't have a clue yet, work their
way through it. At least, that's the impression I got from the
Beginners Guide, And nothing in the 17 arch wiki bookmarks I've added
to my ~/lynx_bookmarks.html so far. Along with the fact that all of
them lend themselves well to using a console browser like lynx. Which
was helpful when I was trying to get X up and running..
> > So as long as the rolling release process turns out to be consistently
> > more reliable than updating a 'buntu system to the next release {by
> > editing the sources list and doing an "apt-get dist-upgrade" (2 out of 5
> > such upgrades really hosed my my 'buntu installs...)}
>
> You did it wrong, according to Ubuntu documentation. Ubuntu (unlike Debian)
> (well, I'm not sure about ubuntu-server...) only supports the GUI update
> manager as an update path (I believe it does a few more things than a mere
> dist-upgrade, depending on the particular upgrade; and by not doing those
> things, you're asking for trouble...). On the other hand, I can't vouch for
> the official upgrade path being terribly reliable (I usually reinstalled in a
> separate partition because there was no way to roll back on the same partition
> if the new release had different hardware problems that I didn't yet figure
> out how to solve).
Yeah I know the "U"buntu devs only recommend using a Gui method. BUT:
1)My 'buntu experience started with "KU"buntu, Where (at least at the
time) the apt-get method WAS still recommended. (kde users didn't much
like depending on a gnome gui tool...)
2) Even now if you look deep enough, there still exist valid
command line methods... For example check out this excerpt from"
http://ubuntuguide.org/wiki/Ubuntu:Karmic
-> Upgrading Intrepid or Jaunty to Karmic
->
-> * Also see the official Ubuntu desktop upgrade documentation.
->
-> There are several methods for upgrades from the command-line interface
-> (Terminal) (which can be used for both the desktop and server editions of Ubuntu/Kubuntu).
->
-> * This is the preferred method:
->
-> sudo apt-get install update-manager-core
-> sudo do-release-upgrade
->
-> * You can also use the update-manager (all editions):
->
-> sudo apt-get install update-manager
-> sudo update-manager -d
->
-> * You can also use:
->
-> sudo apt-get update
-> sudo apt-get upgrade
-> sudo apt-get dist-upgrade
->
-> (Note: the first two lines simply make sure your current distribution is
-> current before upgrading the entire distribution, and are optional.)
Though I note that they don't mention the step of manually updating
the sources list for the dist-upgrade method.
Also I saw something from ubuntugeek that suggested that in between
installing update-manager-core, and running do-release-upgrade one should
edit the file /etc/update-manager/release-upgrades to set Prompt=normal.
I guess I've always tried to use cli methods because I've never been
comfortable attempting major upgrades while depending on the X server.
Now that kde4 has chased me away from using Kubuntu, I still have an
Xubuntu installation, And I think I'll give the do-release-upgrade
method a try when I'm ready to "upgrade" from karmic to lucid
But I gotta say, Arch has become my default boot choice...
Incidentally Isaac, if you've got the spare partition to do a 'parallel' fresh
install, you could still do an upgrade without risking the existing installation...
1) Duplicate current installation on the separate partition.
You could use partimage {I think} But I've always used:
tar -czf filename .
from the mountpoint of the source partition, then after running mkfs
on the target partition I mount that and from it's mountpoint I do a:
tar -xzf filename --numeric-owner .
(of course, as a multi-boot user, I usually have a running Linux in
a third partition to do the tar commands in. (Making a tgz BU of the
current root partition isn't a good idea... {too many moving targets})
2) edit target fstab to reflect it's new location.
3) add an appropriate entry to grub
4) assuming the cloned installation works properly, you can upgrade one,
while keeping the the other untouched...
Well I gotta go to bed soon so, See Ya...
--
| --- ___
| <0> <-> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| ~\___/~ <<jtwdyp@xxxxxxxx>>
