Re: What's the best package manager for single-package upgrades?
> You seem to have a fairly big misconception here: Adding testing to the
> sources.list and doing an apt-get update and upgrade will _not_ reflect
> how many packages are in testing. Not by any stretch.
> First off, apt-get upgrade and apt-get dist-upgrade are very different:
> upgrade will install new versions of existing packages, but only as
> long as it doesn't have to add/remove other packages to satisfy
> depencencies.
> dist-upgrade will install or remove other things as needed to meet
> deps.
>
> HOWEVER, both of these commands are starting from the goal of upgrading
> to newer versions of packages you _already_ have installed. It gives
> you no idea what _else_ might be included in sarge.
That's exactly what I want.
Can you clarify the above -- is there a way to get a list of what you have
that has new versions but don't meet dependancies? I'm not looking for
products that aren't installed, I'm just looking for upgrades for things
which are installing. Testing is showing me _NOTHING_ of any significance.
Only when I prefer unstable do I see upgrades, then it wants a break the
whole world shift :-(
> > Perhaps my product selections are biased: I really could care less about
> > the latest and greatest desktop. They are pretty. But a browser that
> > actually works is required to do my job, for example.
>
> Fist off, you've already had the suggestion offered of using a backport
> for this. Before you get too carried away with complaining that the
> entire Debian process is useless, why don't you try the solution that
> works for so many people.
> Apt-get.org is your friend.
The backports DO NOT fit into the debian framework. I can't use app-get to
manage their dependancies. (unless there is some way to do this that isn't
documented on the site)
> Oh, and on browsers: I've personally been extremely happy with Firebird
> (from the Mozilla folks). It isn't packaged as a deb anywhere I've
> seen, but just unpacking the tarball in /usr/local/bin and running it
> has worked fine for me.
I didn't say "useless", but I did say (and it does appear) that having the
unified application/dependancy management system doesn't help here. I
might as well run another Linux or Solarix x86, because apt-get isn't doing
anything for me here. A given downloaded package (like firebird) might
require something, and I'll have to manage all those dependancies myself.
Oh, and no -- there is no modern Mozilla backports. The most modern
backport is 1.4b4. That's nearly 9 months old.
> > Updates to the
> > wireless drivers to improve device support would be useful. Stuff that has
> > been safe and stable within Sid for over a year now (according to the
> > package pages) still isn't appearing in testing.
>
> Aren't drivers generally part of the kernel, or kernel modules?
> Which in turn are pretty much independant of which branch you're
> running. You can compile whatever version kernel you want under
> woody/sarge/sid... and make-kpkg makes it almost shockingly easy.
Compile and kernel don't belong in the vocabulary of any operation which
needs stable systems.
> If you want a 'stable' system with later versions of just a few things,
> you can use backports or failing that, compile your own.
Why aren't these backports being introduced into testing and then stable?
Why force people to deliberately go outside the package framework?
> If you want an in-between system, run testing with the caveat that just
> before a release, there's not a whole lot of new stuff going into
> testing. (Seem counter-intuitive? I believe the reason is that just
> before a release, the emphasis is on debugging the hell out of all the
> stuff that's already in testing so that it meets Debian's (very high)
> standards to qualify for the name 'stable' in time for release.)
Again, I'm still not seeing anything in testing. Neither the Mozilla nor
the Konqueror or any other browser that I can see in testing has been
updated in the last 2 years, and all of them contain unworkable flaws that
prevent their use in any production environment.
> If you want more newer stuff than that, go ahead and run unstable. It
> seems to only get significantly broken very rarely, but things do go
> wrong sometimes when you run lots of really new versions of stuff.
We have no desire to run unstable, but if that's the only way to have
modern, unbroken versions of business applications then we'd have no
choice, now would we?
--
Joe Rhett Chief Geek
JRhett@Isite.Net Isite Services, Inc.
Reply to: