On Wed, Dec 23, 2009 at 03:16:34PM -0800, Ryan Niebur wrote: > On Wed, Dec 23, 2009 at 11:07:33PM +0000, Tim Retout wrote: > > On Wed, 2009-12-23 at 13:19 -0800, Ryan Niebur wrote: > > > On Wed, Dec 23, 2009 at 04:09:43PM -0500, Jonathan Yu wrote: > > > > On Wed, Dec 23, 2009 at 3:50 PM, Tim Retout <t...@retout.co.uk> wrote: > > > > > So we need to tighten up the Depends to match the version of Perl that > > > > > libdevel-cover-perl was compiled against. > > > > I get these warnings too, and have always considered them more of an > > > > annoyance than a bug. I have been thinking about how to deal with this > > > > issue, but I have not come up with an elegant solution that would suit > > > > our purpose. I'd love to hear about this from the rest of the group. > > > > > > > > > > lets just binnmu them as we find them? > > > > Yes to this. > > > > But to spot these more easily in the future, we can add some magic to > > debian/rules and debian/control to force the dependency. They'll still > > need a binNMU, but I suspect that some automated/manual mechanisms will > > pick this up sooner if it causes an installability problem (hopefully > > without having to involve pkg-perl at all). > > > > It's only a trivial annoyance with 5.10.0 and 5.10.1, but with future > > jumps it could break stuff, in the worst case. > > > > we already have dh_perl which sets perl:Depends for us. perhaps it > could be extended for cases like this to make the dependency break > with new upstream perl versions. I wonder, is there any way we can > tell (from code) that it needs to have the stricter dependencies? >
actually, this already happens. for example, libdevel-cover-perl depends on perlapi-5.10.0. the problem with this is that the new version of perl-base provides both perlapi-5.10.0 and perlapi-5.10.1. so we do have a way to deal with this when it really would matter, the perl maintainers just didn't use it this time (becuase it doesn't really matter). perhaps it really should have been used this time, and we should just binnmu everything that still depends on perlapi-5.10.0? I'm guessing a discussion with the perl maintainer who left it providing perlapi-5.10.0 would be insightful for us. -- _________________________ Ryan Niebur ryanrya...@gmail.com
signature.asc
Description: Digital signature
