.la file removal, multiarch for plugins
(Please CC me on replies, as I'm quite behind on reading MLs. M-F-T
set accordingly.)
Taking this discussion out of bug#633256 and into debian-devel.
On Sat, Jul 09, 2011 at 11:13:47PM +0100, Neil Williams wrote:
> On Sat, 9 Jul 2011 23:06:03 +0200 Lionel Elie Mamane <lionel@mamane.lu> wrote:
>> On Sat, Jul 09, 2011 at 10:29:42AM +0100, codehelp@debian.org wrote:
>>> Package: sqliteodbc
>>> Usertags: la-file-removal
>>> To finish an old release goal from Squeeze, to comply with Policy
>>> 10.2 and to ease the introduction of MultiArch, I'm filing bugs
>>> against packages which contain .la files which can be either removed
>>> or stripped of the dependency_libs variable.
>> Policy 10.2 says:
>> These requirements for handling of .la files do not apply to loadable
>> modules or libraries not installed in directories searched by default
>> by the dynamic linker.
> All true, but (...) clearing the dependency_libs field in the .la
> file is still necessary even if the .la file is retained for the
> purposes of things like libltdl. (It is also safe for libltdl usage
> as this relies on a different part of the .la file.)
OK. What is slightly unclear to me, is that "being loaded by libltdl"
is a thing that is external to the package. If there is *one* program
anywhere (even not packaged in Debian or local to an enterprise) that
uses libltdl to load library foo, we break that program by removing
the .la file. So I don't really understand why we (we=Debian) consider
it a good thing to remove the .la file, even if nothing in Debian, or
nothing we know of, uses libltdl to load that library.
> With MultiArch, you may still get problems here because those
> directories will be changing. If those paths are within the sole
> control of this package, fine - both parts can change at the same time.
> If you're relying on paths which come from a separate source package,
> it'll likely break.
I suppose we'll have a controlled / synchronised migration for all
ODBC drivers? Or should each driver just unilaterally stick
$(dpkg-architecture -qDEB_HOST_MULTIARCH) somewhere in the path?
I presume that
/usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/odbc
is better than
/usr/lib/odbc/$(dpkg-architecture -qDEB_HOST_MULTIARCH)
This would work for ODBC drivers because they are registered anyway,
so really, (if I understand well) as far as the ODBC libraries and
applications are concerned, they can be anywhere. Nevertheless, IMHO,
it would be "cleaner" if all ODBC drivers made the same choice.
Other loadable libraries (typically plugins / extensions; I'm thinking
of my xchat-guile package here) that are dlopen()ed or loaded using
libltdl, I presume the loading application will have to be fixed to
lead from a multiarch path anyway, so the plugins have to wait for the
app to do it first.
--
Lionel
Reply to: