[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#629472: Handle deprecated modules in 5.12 and 5.14



On 2011-08-07 15:33, Dominic Hargreaves wrote:
> [CCing lintian maintainers in case they offer any relevant advice]
> 
> On Sun, Jul 31, 2011 at 10:13:54PM +0100, Dominic Hargreaves wrote:
>> On Mon, Jun 06, 2011 at 10:07:14PM +0100, Dominic Hargreaves wrote:
> 
>>>> Yet to analyze: Devel::Dprof and Perl4::CoreLibs. Assuming that wheezy
>>>> releases with 5.14 and not 5.16, if we catch all uses of these before
>>>> wheezy releases, we won't need to add Depends in wheezy+1 (but this
>>>> assumption may turn out to be invalid).
>>
>> This is looking very likely now, which is even more reason to do this
>> analysis. I'll try and get this done soon.
> 
> I've made a start on this. I only found one package which uses
> Devel::DProf (libapache-db-perl) and filed a bug for that (#636952).
> 
> The perl 4 libraries are more interesting; there are 127 packages
> which appear to have files which use one or more of them. In many cases
> it's likely that the files which use them either aren't installed, or
> aren't used if they are. It's also possible that there are a couple of
> false positives there, where there are private copies of the files
> which are being used directly.
> 
> [...]
> 
> I'm also concerned that it will be difficult to get an accurate
> representation of the issue with lintian; I generated my list of packages
> by grepping source packages for the names of the libraries, then manually
> processed the list stripping out lots of noise. It's possible one could
> come up with a definitive pattern of ways in which the libraries could
> be loaded from a perl script (do/require/use, single or double quotation
> marks, ..?), but possibly tricky.
> 
> Any comments or suggestions welcomed.
> 
> Cheers,
> Dominic.
> 

Hi

I see a couple of advantages of creating a lintian check for this.

First off, we could make this check work on binary packages, which would
solve the problem, where the offending scripts are not shipped.
  We would not catch the ones in the source package which is actually in
use during build (e.g. as a part of tests).  However, these can
"trivially" be caught by re-builds later.

Secondly, writing a lintian check for finding the "average" offending
scripts ("use Deprecated::Module;" or "require Deprecated::Module;")
will probably not take a lot of afford compared to the amount of
true-positives it finds.
  Particularly, if done correctly we can re-use the check for the next
round of deprecations with very little maintenance overhead.

As you mentioned, it can be tricky[1] to find all instances; but if
Lintian can find the easy 80% (or whatever) with some simple heuristics,
then you only have to worry about the last tricky 20%.
  We can always start with an experimental tag, that you check up on.
If it has a lot of false-positives, we can try to revise the checks.

~Niels

[1] tricky as in "solving the halting-problem"-tricky


Reply to: