[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Slink to Potato

Hi Mark Brown; unless Mutt is confused, you wrote:
> Damir, are you sure mutt is using vim?  If you have nvi installed and
> haven't adjusted the alternatives vi will default to that and if you
> normally use a shell alias to select your vi mutt won't pick that up.

Yup, I'm positive. I am a control freak and I usualy do not have
multiples of anything. That is why I use dpkg command line for anything
above the base system, and keep track of what is installed. It should
work now, I think it was an error in  my syntaxes of the .gvimrc file.
> That idea is intented to be closer to unstable than stable - at this
> point, there would probably be as much hassle updating to the in-between
> release as there is updating to Potato.  Not that there's much hassle
> with Potato right now.

Sorry, but I tend to think there is a bit more work involved in getting
libc2.1 installed than it is to get wmaker 0.61.0 (as an example). Say,
if I feel bored over the weekend; what packages and in which order do I
need to update to get the system to potato- with dpkg command line _not_
the apt tool? I'd guess libc6 2.1, bash, ldso, libreadline2g and so on
and so forth. (any volunteeres for a quick how-to? :-) )
Now, I want new wmaker (assuming there is a package): I do dpkg --i
wmaker* and two or three other small packages, and I'm off to the races.
Since it is a bug-fix release, I don't think anything will break. If it
does, I pull out old packages, do dpkg --i thingy, and I'm safe. An hour
work, at the very worst.

> The stable GNOME packages are actually produced by the Debian
> maintainers - they're just distributed from the GNOME site.

So, why would they not be introduced into slink-proposed-updates?

> To explain it a bit more clearly: glibc 2.0 is binary compatible with
> glibc 2.1.  If programs break when linked against 2.1 then that is a bug
> in the program (typically trying to use internal features).

With all due respect, from my standpoint it doesn't matter where the bug
is. The fact the program may not run does matter.


Reply to: