Hi Niko,
thanks for your message and the included hints!
Am Donnerstag, den 15.10.2009, 09:05 +0300 schrieb Niko Tyni:
> I suppose a workaround could be to somehow generate dependencies like
> Depends: perl (>= 5.10.1), perl (<< 5.10.2~)
> and require binNMUs every time the perl version changes.
Yes, this is just a workaround, so I'd not like to go for it.
> 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?
> 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.
Best regards
Manuel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
