retitle 318762 libapache2-mod-perl2: should ship API docs for 1.99* API severity 318762 wishlist thanks
The only valid complaint in this bug report is the fact that we don't include pre-2.0 API docs in sarge. Debian makes absolutely no guarantees that the version of a package shipped in a stable release will match whatever the current API is on its upstream website. On Sun, 2005-09-04 at 13:13 +0200, Georg Bauer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > > I'm afraid you will be out of luck here, if I understand the issues > > correctly. The official release of mod_perl 2.0 never made it to > > Sarge, > > the 1.999.21-1 packages in Sarge is a pre-release. The problem was > > that > > shortly before mod_perl2 went stable, the upstream developers decided > > to rename lots of things in the API, and Sarge shipped the old API. > > Thus, mod_perl 2.0 as shipped with Sarge won't run in the rest of the > > world, and vice-versa. Also, the documentation will be confusing. > > Sorry, but this is really stupid: the version in Sarge is not usefull > to anyone. It's not compatible with older mod_perl versions and it > isn't compatible with the current release, too. Either get it fixed That's incorrect; older libapache2-mod-perl2 releases (that were called 1.99*) had similar APIs. It was only after they discovered bugs that they were forced to change the API to what is used in the final mp2 release. This happened after sarge had frozen, so there was nothing that could really be done without massive upheaval. > > by introducing the current mod_perl 2.0 or throw it out - but don't > let some weird in-between-version stay in the stable release. People No. There are packages in Debian stable that require the 1.99* API, so upgrading to the latest 2.0 release and/or throwing out the existing packages is not an option. > > that upgrade from Apache 1 to Apache 2 and use mod_perl will have to > port their application to mod_perl 2 - but on Sarge that means that > they will have to do the port again when the next stable comes out - > somewhere in the next 3 years, if Debian stays as speedy as it was up > to now ... That's correct. Debian doesn't guarantee that we will provide compatibilty for people's custom applications across stable releases; it is expected that people will have to actually test and make sure things work when they do an upgrade to a newer stable release. If that requires porting work.. well, so be it. Our stable releases do not change APIs in point releases for no good reason (and I don't consider "it might possibly make future upgrades easier" with no real proof to be a good reason). Besides, how do you know that they mp2 people won't change the API yet again before etch releases? People may have to port to a new API anyways, even if we were to update the sarge packages; you don't know what will happen. > > > So, well, this isn't a good situation, but it is something we have to > > live with. > > Sorry, no, but that's not acceptable - at least make a clean cut and > throw this broken version out of Sarge, it will pose more problems > than it solves. > I think the people whose packages depend upon mp2 will disagree. > Of course it would be even better to replace it by the final 2.0 > version. If it really was an interims version it shouldn't have gone > into Sarge in the first place or should have marked as some special > version - something like mod-perl-snapshot or something like that. > But the current situation isn't something to be proud of or something > that can be just left in it's current state. > It was not interim, it was expected that the final mp2 would contain the same API; and upstream was calling the releases "mod_perl2". If you have any complaints, complain to upstream about changing the API right before releasing mp2 2.0. I don't think you'll find much sympathy, though. > And I don't think that requiring users to patch a stable release > that's just some months old because of this is a solution - it's > definitely a fix that should go into a point release of Sarge. ...Which would require updating mp2's dependencies, would introduce an API change in a *stable* point release (so people already using the 1.99 API would find their applications broken), and introduces a very real possibilty of breaking a bunch of stuff. How about not? -- Andres Salomon <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
