Bug#549447: findimagedupes: unusable

Niko Tyni ntyni at debian.org
Sun Oct 18 18:05:55 UTC 2009


On Thu, Oct 15, 2009 at 02:28:07PM +0200, Manuel Prinz wrote:
 
> > However, this means the Inline'd code would need to be moved to a separate
> > module ("used only for modules"). That seems easy to do though.
> 
> This seems to be the proper solution and easy to do. Is there a special
> naming convention and location for modules that are private to apps?

I think the existing /usr/share/findimagedupes/lib would be fine.
As for the naming convention, maybe the App:: namespace on CPAN would do?
OTOH as long as they're private nobody should care.

> > FWIW, the few other packages depending on libinline-perl don't seem
> > to be broken.  I looked at libogg-vorbis-header-perl (which uses the
> > VERSION parameter) and it's loading the C extension fine.
> 
> Right. But also none of them seems to include the .inl file. Could the
> libinline maintainers please comment on whether this file (and others
> generated by libinline) is/are needed? The perldoc does not really
> clarify it from a distribution point of view for me. libogg-v-h-p seems
> to work well without them.

It seems the standard way to go is with Inline::MakeMaker. Here's
a lightly tested patch that seems to work for me, hope you find
it useful.

I tried to be non-intrusive, but I couldn't resist reworking the
sed parts of debian/rules a bit. YMMV there of course :)
-- 
Niko Tyni   ntyni at debian.org


More information about the debian-science-maintainers mailing list