Re: how to handle newer versions of the modules in perl-modules?
>>>>> "Ardo" == Ardo van Rangelrooij <ardo@debian.org> writes:
Ardo> I don't see a reason why not. From a source tarball one
Ardo> could create a seperate binary package for each module and
Ardo> have 'perl-modules' then depend on all of them. From a
Ardo> package bloat point of view this is not what we want to do,
Ardo> but it is possible.
Why? That's a horrendous amount of pointless work for *no gain*. I
suggest you go familiarise yourself with how perl (the distribution
not the language) works. Upstream have gone to great lengths to avoid
exactly what you're proposing.
Ardo> Ok, I'll look into that.
If you choose not to package Test::Harness yourself, I'm happy to do
it for you. I already have quite a collection of perl packages; one
more is nothing.
Ardo> One potential issue I see is that in the long run
Ardo> 'perl-modules' gets a long 'Conflict/Provides/Replaces'
Ardo> list. But let's cross that bridge when it comes to that.
Again, no. lib*-perl packages have *no reason* to interact with
perl-modules & vice versa. There are no diversion, no alternatives
and no 'Conflicts/Repplaces/Depends' required. It is even possible to
install modules locally, by hand yourself without fear or trepidation.
Read the perl policy & become enlightened (a hint: consider the output
of perl -V).
Ardo> Another potential issue is that a newer version might break
Ardo> the API of a particular module.
That is possible and the eaiest answer is packages that break in the
face of ABI changes adjust to the ABI change and 'Depend' on the
lib*-perl package because these ABI changes will, eventually, make
their way into perl-modules. It will just take a new upstream
release.
--
Stephen
"If I claimed I was emporer just cause some moistened bint lobbed a
scimitar at me they'd put me away"
--
To UNSUBSCRIBE, email to debian-perl-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: