Re: discussion on perl module packaging
>>>>> On Tue, 17 Oct 2000 10:42:39 -0700 (PDT), "Sean 'Shaleh' Perry" <shaleh@valinux.com> said:
Sean> On 17-Oct-2000 Stephen Zander wrote:
>>>>>>> "Sean" == Sean 'Shaleh' Perry <shaleh@valinux.com> writes:
Sean> Problem is, there is no way to determine what package a perl
Sean> module came from. Further, lintian may be checking a package on
Sean> a machine where neither the package or any of its dependencies
Sean> are installed.
>>
>> The two relevant statements in perl are
>>
>> use Some::Module;
>>
>> and
>>
>> require Some::Module;
>>
Sean> this is already done
>>
>> or the perl equivalent. To perform this check where the relevant
>> package *is not* installed requires access to Contents-$(arch).gz.
>> You may have to generate your own, cut-down version and include it
>> with the lintian package.
>>
Sean> currently there is such a list in lintian. Problem is that it
Sean> is ALWAYS out of date. I would like a solution that does not
Sean> involved a file distributed with lintian.
Sean> Problem with the contents file is that it a) requires net
Sean> access or b) requires lintian be run on a mirror. I could add
Sean> a --on-mirror switch, but I was hoping we could come up with a
Sean> better answer.
It seems to me that lintian will be run in two situations most
commonly and other situations should be ignored as uncommon
1) On a central debian server where a full and current Contents file
is available.
2) On a developers machine where the perl module being used should
already exist (else how are they testing).
So my suggestion would be to
1) Use a contents file specified from the conf file if it specifies
one.
2) Use local *.list files if not 1.
3) Print an error when neither 1 nor 2 contain the package.
Jim
--
@James LewisMoss <dres@debian.org> | Blessed Be!
@ http://jimdres.home.mindspring.com | Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach
Reply to: