Then you could have the solution of say changing the name of the package to perhaps reflect that in fact you have perl4 or something and just install incremental upgrades for the packages that aren't prone to breakage. Eventually as people upgrade their stuff. You could slowly retire the old stuff while supporting the new.
On Mon, 10 Apr 2000, Phil Pennock wrote: > Typing away merrily, John Haggerty produced the immortal words: > > Is there a good example of something in debian breaking a general > > script/program server side? > > Not that comes to mind. > > But what happens when, eg, perl is upgraded to 5.6? The perl4 -> perl5 > transition broke enough stuff. Will this new one break things? If so, > will Debian fork perl just to maintain backwards compatibility? > > The ISP where I work still has perl4 on its servers, for this very > reason. When a customer has something which works, they can be very > reluctant to make modifications just to use a newer version. > > Predicting the future is tricky. Being defensive in the way that you > set things up can help you bypass some of the uncertainty. > > Defensive SysAdmin-ing as opposed to Defensive Programming. :^) > -- > HTML email - just say no --> Phil Pennock > "We've got a patent on the conquering of a country through the use of force. > We believe in world peace through extortionate license fees." -Bluemeat > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
