> > > That's actually a very valid point I had forgotten about, but > > > that's not what I originally meant above. > > > > > > Using some mythical package with version 1.4, 1.5 and 1.6 for > > > example, I find it's quite common in the web hosting world that > > > you have to provide version 1.4 for someone and version 1.5 for > > > everyone else. After version 1.6 comes out, some users of 1.5 > > > upgrade, but the rest choose not to. > > > > > > Dealing with that is non-trivial... > > > > it seems even not possible to me, or that would need some tweaks to > > apt/dpkg .... > > Well the way you do that kind of thing now is with > mythical-package1.6, mythical-package1.4 and so on. Note the > reactions from people when request tracker had to do that. I note it, and I support those reactions. we have a lot of web apps, and I think the number will grow fast (faster than binary traditionnal apps). and we cannot have a package per ( version × webapp ). Moreover, IMHO, keeping an older version of a web app come from 2 reasons : * upgrade is too hard / too risky (in a wep app PoV) * ppl have customized / changed it a lot (2) is not of our concern (1) is sth we should work on. At least, if we have many apps in the archive (like rt does) there should have a strict policy, like : * not more than 'n' packages (n kept small like 3) * package *has* to be supported upstream or by the packager, with reasonnable reliability (especially wrt bugs >= important), else it has to be removed from the archive. * those package should not be apps that are trivial to upgrade (putting the fact that maybe users may have done changes aside) I believe rt fits most of the conditions here. -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Attachment:
pgpAA7wLJc2nh.pgp
Description: PGP signature