Re: Recommendation for mixed environment?
Hi Gabor,
Gabor Szabo wrote (27 Nov 2013 10:12:47 GMT) :
> That's when you need some mixed solution. Some perl modules from
> Debian and some from CPAN.
> What would be your recommendation for such situation?
In this case, what I generally do is one of these:
A. First, build a quick'n'dirty .deb for every module that is not in
Debian yet, thanks to dh-make-perl magics (cpan2deb).
Once convinced I really need this module (if I'm writing the
consumer code myself), then I'll most likely polish the packaging
and upload it to Debian (and stable backports) in the end.
But I can't let the NEW queue processing block my development, so
I may also upload these .deb's to a non-Debian APT repository in
the meantime (reprepro is good for you), so that I can deploy the
dependent code with APT only, without waiting for the packages to
reach Debian.
B. Use a dedicated local::lib tree to install non-Debian modules in
a way that they're only visible for the application that needs it,
and not system-wide.
Over the years, thanks to the incredibly awesome Debian Perl team's
workers, tools and process, I'm doing B less and less often, and
A most of the times.
(Almost OT, but let's take it to the root of the "problem": I think it
would be even easier to rely less on non-Debian modules if we, as the
Debian Perl team, got more input from the (Modern) Perl community wrt.
what are the modules needed to implement nowadays' best practices: if
this was the case, then presumably we would {request,package,upload}
new stuff preemptively, rather than at development time, when
realizing "oh, MooX-Late is not in Debian yet!" as occurred to me
a few weeks ago. I guess that the best of Task-Kensho-* could be used
as a starting point, but I see many of them were not updated in years
and are probably not representative of today's best
practices anymore.)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
Reply to: