also sprach john <johnpf@atnet.net.au> [2002.01.11.0342 +0100]: > We have come to a point where we would like to use some software that is > currently in woody on a production server that is currently running > potato. it's about time ;^> > Now we have a few approaches as I see it: > > 1) We install the packages from upstream source into /usr/local/ > > OK, we're talking about openssl, curl-ssl, perl, libssl, apache, > apache-ssl, php etc. Might be a nightmare to maintain in the future. > And since we'll be selling boxes with all this set up on them it's going > to make things much more expensive for us. yes, it'll be a nightmare. i usually do this for 1-4 packages at the most, if debian hasn't packaged them. but i *hate* it. i am thoroughly spoiled by Debian ;) > 2) We upgrade to testing. > > Is it safe? <image of Marathon Man>. Who is running production servers > on testing? what if any issues have arisen? we are. at least 15 of them. i can give you exact counts tomorrow. sure it's safe... noone forces you to apt-get dist-upgrade everyday (there are bugs that come in that way), and you'll have to get down with apt's pinning to make sure to keep the versions you want and not to upgrade them. furthermore, you have to keep track of what's secure and what isn't. (we're a network security company, so that's a nice side-effect). > 3) We build the Debian packages from testing on stable. > > I've tried this, and either got it wrong <quite likely> or it just > doesn't work like that as build curl-ssl then wants perl, which doesnt > want libdbi-perl. It wants a libc6 upgrade. Which might (will it?) break > other things etc etc. you need a lot of -dev packages for this to work. my advice (i do this occassionally to get packages from unstable into testing): get yourself a $500 pizzabox machine that you'll use for exclusive repackaging, install basically all *-dev on it, along with debhelper et al., and then it should work. after all, the maintainers do nothing else (okay, they don't have all *-dev (i do), but you also don't need all. just try dpkg-buildpackage until it works, fixing dependencies as you go. or check Build-Depends of the package...) > Any advice as to how to best manage this is appreciated - I'm > particularly interested in the opinions of anyone who has actually > _done_ this sort of thing. i do all three. we're running woody, have been for half a year (it's getting better by the day, one can *feel* the impending freeze), i occassionally get packages from unstable into the woody systems (early) by method 3, and some software that's not available as .deb, i install from tarball in /usr/local. if i have time, i try to package it into a .deb just to make dpkg know about it. > Is there a safe and stable way to build/install woody packages onto a > potato system other than to dist-upgrade to woody? what's from with dist-upgrade? but you can just update your sources.list to woody, then simply install what you want, and watch as *a lot* of dependencies stroll along... libc... base stuff... a bunch. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck the remote desktop feature of windows xp is really nice (and *novel*!). as a micro$oft consultant can *remotely* disable the personal firewall and control the system. we'll ignore the fact that this tampering with the firewall is not logged, and more importantly, that the firewall isn't restored when the clowns from redmod are done with their job.
Attachment:
pgpelfTEpVXOh.pgp
Description: PGP signature