On Wed, Feb 02, 2005 at 02:38:10PM +0100, Florian Weimer wrote: > * Matthew Palmer: > > > On Tue, Feb 01, 2005 at 06:27:30PM +0100, Florian Weimer wrote: > >> * Lars Wirzenius: > >> > >> > ti, 2005-02-01 kello 15:25 +0000, Stephen Quinney kirjoitti: > >> >> This is the 3.4 series of RT, it can be installed alongside the 3.0 > >> >> and 3.2 series without any problems. This release is a big > >> >> improvement over previous versions and features many new features, > >> >> substantial performance improvements and a significant cleanup and > >> >> restructuring of the codebase. > >> > > >> > What is the a reason every version series of Request Tracker needs to be > >> > packaged, instead of having a single request-tracker package that gets > >> > updated with newer versions? > >> > >> Request Tracker is a development framework for trouble ticket systems. > >> Users are encouraged to add new code to its (Perl) packages, and > >> there's an overlay mechanism to support this. > >> > >> Unfortunately, this makes updates non-trivial, at least sometimes. > > > > So you do a bit of testing before madly apt-get dist-upgrading your > > production servers. What a concept. > > As Andrew noted, we already do similar things for library packages. > There's a growing trend to provide different version which can be > installed in parallel for other infrastructure packages, too (IIRC, > PostgreSQL is heading in this direction, too). > > As a user, I think this is very convenient. The ability to switch > back to a known-to-work version by tweaking a few configuration files > is reassuring, even if you've tested the new software version on an > indepedent machine. So archive bloat is not a problem for you, and "apt-get dist-upgrade" not actually providing upgrades to the latest versions of everything is perfectly fine? Ability to switch back is provided by backups and planning, not by having a million versions of a package in the archive. If you really want this, work out a way of installing multiple versions of the same package through path redirection. Libraries are the way they are because they are the way they are. If they weren't the way they are they wouldn't be the way they are. If RT's a library, start defining API compatibility and package it like a library -- lib* prefix and all, so people know what they're getting into. - Matt
Attachment:
signature.asc
Description: Digital signature