On Thu, Nov 06, 2003 at 11:46:30AM -0800, Joe Rhett wrote: > > 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 :-( What I would do is this: Comment out all the "stable" or "woody" sources in sources.list (you could just as easily delete them, but I like keeping stuff) Add all relevant sarge sources apt-get update apt-get -s dist-upgrade This will do a 'simulate' run of the dist-upgrade. Don't bother with 'upgrade' at all. It doesn't have enough freedom to really get anywhere (between branches, lots of packages end up with different dependencies or some library gets renamed or whatever, and 'upgrade' won't install new packages to meet the new dependencies, so nothing happens). If you like what you see, run it again without the -s > > > 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) Well, what I do personally is a little clunky but seems to do the job: When I find a backport I want, I add its deb line to my sources.list, then do an apt-get update, then an apt-get install of the package. I then immediately go back to my sources.list, comment out the line, and apt-get update again. This way, when I'm installing the backport, apt can draw on both the whole official woody tree, plus the site where I'm getting the backport (to meet any dependencies). BUT, when I later fire up aptitude to install something or check for new security fixes, I don't end up with "newer" unofficial versions of god-knows-what getting installed from all those backport sources. There may well be some elegant way of doing this with apt's "pinning" feature, but I don't understand pinning and it scares me, so I stick with this method for now. > > 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. It's true. In the particular case of installing something that's not packaged as a deb file, apt is not doing anything for you. In firebird's case, it does not seem to depend on anything, and the simple expedient of untarring it has given me the only browser I need. > Oh, and no -- there is no modern Mozilla backports. The most modern > backport is 1.4b4. That's nearly 9 months old. Bummer. > > 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. In that case, I'm fairly sure you can just download and dpkg -i a pre-built kernel from any of the three branches. Don't quote me on this, as I've never actually tried it, but I _think_ that kernel-image packages don't tend to have dependency issues... so you could install a kernel-image-2.4.22 or whatever from sid on a woody or sarge system if you like. > > 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? Um. They're not introduced into stable because nothing is. Once it's released, it's frozen. Not being a developer, I'm not the person to try and explain the reasoning behind that. And they're not introduced into testing because they're specifically compiled against the 'stable' versions of all the libs and dependencies and stuff. > 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. Crappy. I can't answer for that. Not something I know anything about. > > 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? If having sid's version of mozilla is more important to your needs than having a rock-solid system, AND the latest backport is not a good enough compromise for your needs, AND you don't want to run a non-debian-packaged browser (thus having to manually manage any dependencies), then you probably will end up choosing to run a sid system. The way I see it, that is your choice. It ain't perfect, but I really don't see how it forces you to run sid... Looks to me like it forces you to look at your priorities, and choose which are most essential. Cheers! -- ,-------------------------------------------------------------------------. > -ScruLoose- | Reporter: What do you think of western civilization? < > Please do not | Ghandi: I think it would be a good idea. < > reply off-list. | < `-------------------------------------------------------------------------'
Attachment:
pgpOLBUTNahLX.pgp
Description: PGP signature