On Tue, 22 Feb 2011 22:28:05 +0000, Roger Leigh wrote: > > > perl (>= 5.10) | libmodule-build-perl > > Could you please explain what's "pointless and/or broken" about that > > one? > > (Except that it's old since even lenny has 5.10.0. > Yes, that's exactly the reason. Because the perl (>= 5.10) is > satisfied under all circumstances, the libmodule-build-perl > alternative is entirely redundant.
Right, and we (as in the pkg-perl team) update those routinely when we do new uploads for newer upstream releases or bugfixes. > > perl (>= 5.10.1) | libtest-simple-perl (>= 0.88) > > perl (>= 5.12.3) | libmodule-build-perl (>= 0.3601) > These are more recent, but even for these cases the versioned > perl dependency without the alternative is entirely adequate for > building purposes. Depends on the target -- the second example would only build with the perl version from experimental. It's a way to achieve: - avoid installing libmodule-build-perl if someone has already perl 5.12 on their machine - prepare for the perl 5.12 move to unstable > > For perl packages: if Module::Build, Test::More, etc. (as dual-lifed > > modules) are in two packages, I see no point in not allowing them > > both. And this makes backporting, building "at home" etc. easier. > That's definitely something we should not be making harder. One > problem with the alternatives is bitrot though, if they are just > left. They should be actively tested, and dropped eventually. Agreed, that "cleanup" needs to be part of the maintainance routine. > For the examples above, it definitely makes sense for backporting. > For others, it's not quite so useful. Ok, I can agree on that, too :) Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `- NP: Big Bill Broonzy: How do you want it done
signature.asc
Description: Digital signature
