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