On Fri, Sep 05, 2008 at 08:08:08PM +0100, Adam D. Barratt wrote: > On Fri, 2008-09-05 at 11:15 -0700, Russ Allbery wrote: > > Niko Tyni <[EMAIL PROTECTED]> writes: > > > > > The implementation could use corelist(1) and/or Module::Corelist to > > > check if the version in the dependency is already in the core. I think > > > just transforming libfoo-bar-perl to Foo::Bar would catch most issues, > > > and the rest (like podlators-perl -> Pod::Man) could be special cased. > > > > One trick here will be that lintian.d.o runs on a stable system and hence > > would have stable versions of those utilities unless we add newer versions > > to a private library directory. We can do that, of course, but it may be > > worth considering whether we should generate some sort of static dump of > > the data and update it periodically instead. I'm not sure off-hand which > > would be easier to maintain, or if there's some other, better way. > > How often do new (packaged) modules get merged in to the core? On the > assumption that it's not a hugely regular occurrence, I'd be minded to > suggest maintaining a static copy, as we do with the doc-base section > list.
My hunch is that new modules mostly get merged with major releases (5.8, 5.10 etc.). I'm not aware of an official policy about this, and the 5.8 series did incorporate at least DBM_Filter and Pod::Perldoc in minor releases. There's the separate libmodule-corelist-perl package that should be trivial to backport for stable; it might be a good candidate for volatile instead... Hm, on a stable system lintian can't even determine the current Perl version in unstable without hardcoding it. A static copy is definitely needed. The copy will need to be updated more or less manually: the lintian build process can't regenerate the list on every build because the package for stable is (presumably) built on stable. OTOH, the build process could warn or even abort if it detects that its copy is out of date wrt. the installed Perl version. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
