On Thu, Feb 03, 2005 at 11:31:55AM +1100, Matthew Palmer wrote: > 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. I agree with this absolutely. Anything in production should be being watched carefully when apt-get upgrading if it's not running stable. If it is, you only have to watch it, not watch it carefully. ^_^ However, I think the sentiment is misplaced in this discussion. I also think the next paragraph is equally misplaced. There's good reasons for multiple libraries, and we have sonames to account for that. There's _different_ (albeit parallellable) reasons for this discussion, and here the waters are just being muddied. > > 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. I have to say, I prefer the ability to parallel-deploy, so I can give certain users (the ones who don't panic and start deleting things when they get an error message) access to newer systems for acceptance testing against production data. > 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. I'd like apt-get dist-upgrade to fetch me the latest version of something (in the Debian distribution I'm using, obviously) that's either not going to break things, or will break things and has a NEWS.Debian file that apt-listchanges can beat me with. We could after all extend your arguement against multiple versions of things in the archive to the Debian distribution itself. Instead, I'm going to extend the argument for multiple Debian distributions to request-tracker, since it is a large piece of software which is highly locally-modified by many of its users, and which an automated upgrade between releases is difficult. I'm not saying this is true for all applications, or even most. For FreeRADIUS, I'm currently in two minds as to whether I should put a freeradius version into experimental or just move straight to 1.1.0 when it is released, and hope for the best. I will probably do the latter, since we go to great lengths to be sure the upgrade is easy. However, things like apache where configuration and APIs have changed significantly are obviously easy candidates for this sort of thing. I can't see _any_ circumstance I'd want apt-get -u dist-upgrade to replace Apache 1 with Apache 2. I think the line is best guided (only guided, not dictated) by the upstream attitude. Is the older version deprecated/unsupported, or is it "stable" (as compared to development) and actively supported with bugfixes and security updates in parallel to the new version. That should give a guide as to the usage patterns of the users of that software, if nothing else. I'm not gonna get stuck into archive-bloat. I consider it a risk of unstable, and basically ignorable in stable (how often are you dist-upgrading a stable machine?) but I was spoilt by living on campus with an on-campus mirror for my unstable machines to beat upon, so I can't say I've suffered at all from it. > 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. It's not a library, it's a large data-driven application, and the framework that data's structured into changes between releases, making it hard to autoupdate the data to match the new library. I think bringing libraries into the dicussion was another poster's... straw man? (I'm not sure that's the right logical fallacy) and doesn't help at all. I will say, I'm not _100%_ convinced that request-tracker needs to have 3.4 and 3.2 packages, but I am certainly more convinced of that than I am convinced that there's no need for seperate packages. _My_ usage of it is probably one that could survive a dist-upgrade to 3.4, but I'm only one user who hasn't bothered customising it much. -- ----------------------------------------------------------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Anu.edu.au "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. -----------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature