Duncan,
Thanks for the great explanation. For the first time I feel that I
have something more than a vague understanding of what is happening in
my new system. I do have one or two bones to pick though:
1) I believe that 2004.3 is 'deprecated' (not depreciated) since the
other day when I did an esync it told me so.
2) I also did the manual upgrade and for a while I had quite a few
pieces to keep. ;-) Because of that I disagree with your reasoning of
"the ability to give up and try again later, if desired." When I had
pieces I couldn't move forwards or backwards. I had to double check
things, download the scripted way, dig through the Makefile, and piece
my system back together. Therefore I believe that once you start you
are pretty much committed to finishing or backing out. I tried to give
up but didn't want to keep the pieces. As difficult as it is Humpty
Dumpty can be put back together again with enough patience! ;-)
Thanks again for taking the time to explain the situation. I also agree
with whomever said that your explanation should make it into the
documentation somewhere.
Best Regards,
Tres
On Thu, 2005-04-14 at 04:53 -0700, Duncan wrote:
> Mark Constable posted <[EMAIL PROTECTED]>, excerpted
> below, on Thu, 14 Apr 2005 20:09:25 +1000:
>
> > Forgive my serious level of cluelessness but what practical benefit is
> > that compared to running the occasional 32bit app via the emul libs ?
> >
> > I'm trying to weigh up whether I should burn another week in a, so far,
> > fruitless exercise of upgrading.
>
> Well, in all honesty, not a lot. The primary benefit of 2005.0 is in
> preparation for 2005.1, which will be better in this regard (probably
> ~amd64 level, as I put it in my other response, which see for the sordid
> details <g>).
>
> As to whether it's worth the upgrade now... That depends. 2005.0 is a
> difficult upgrade, no question about it. 2005.1 and full multilib will
> likely be similarly difficult, but in different areas. While staying with
> 2004.3 will certainly be the easiest at this point, do you /really/ want
> to try the task of upgrading TWO difficult levels at the SAME time, when
> 2005.1 comes out? I know *I* don't!
>
> However, there's probably some middle ground. Hopefully, by the time
> 2005.1 gets into betatest mode (that is, by the time you see posts
> mentioning test stages and/or profiles), one would /hope/ the problems
> with the 2004.3->2005.0 upgrade have all been mapped out and solved. At
> that point, that upgrade ///might/// be easier, allowing you to do it, and
> then the 2005.1 upgrade, which should indeed be worth the trouble, for
> anyone doing 32-bit at all, later.
>
> Three other comments:
>
> One: I've no data on this but it's somewhat reasonable that the upgrade
> might be easier if running the latest packages, which of course means
> ~amd64. The upgrade wasn't easy here, but I did it (using the manual not
> the scripted method BTW), and I'm running ~amd64. Again, as any
> statistician will agree, one upgrade makes an anecdote, not a trend, but I
> know I've seen outdated "stable" versions of something or other be the
> cause of issues before, and I know what I run...
>
> Two: There's always the possibility of staying with your current profile
> until it's depreciated, at which point a recommended alternative is
> provided, along with support (to the extent possible in a community
> distribution) for the upgrade. Since I'm a leading-edge guy, that's not
> an option I'd find conceivable, but there's another point to bringing it
> up as well. Until that happens, any urgency in upgrading is your own --
> you pick the best time, and there's the ability to give up and try again
> later, if desired.
>
> Three: If you aren't using and don't expect to be using 32-bit libs or
> apps any time in the near future (into 2005.1, anyway), there's always the
> 2005.0/nomultilib profile and option. I've not looked at the consequences
> of switching to that re moving back to multilib in the future, but it's
> possible it'd solve the profile update issues today, again, **IF** you
> don't use 32-bit (save for grub, where there's the statically linked bin
> package available) anyway.
>
--
--
[email protected] mailing list
