Hi Lionel, On Sun, Jul 10, 2011 at 04:48:16PM +0200, Lionel Elie Mamane wrote: > >>> 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. If we're talking about shared libraries, this is a non issue. the .la file is named like the .so symlink, i.e. without the soname; dlopening a shared library without specifying an soname is Broken and Wrong. So there's no reason for us to worry about breaking something that's already entirely broken. For plugins / DSOs, it's important to not break compatibility with other software that might be opening them in a way that references the .la file, true; but in most cases these are plugins for a specific piece of software, so we know conclusively whether or not the .la file is used for the lookup. In this respect, ODBC is a special case. The UnixODBC documentation and examples certainly all use the .so, not the .la, but ODBC drivers can also be used directly without going through the driver manager, and if the .la exists on the system then it's always possible that someone has referenced it in their odbcinst.ini, too. So if you are concerned that users are referencing a .la file for an ODBC driver, it's not a bug for you to leave it in place indefinitely. However, I think this is a really small compatibility break and would personally not worry much that this would have an impact on users. > > 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. I think it would be premature for ODBC drivers to switch to multiarch paths. There would be no benefit, because the ODBC driver manager doesn't have a search path for drivers that includes any multiarch paths, so you would have to hard-code the driver path in the odbcinst.ini - so then it's architecture-specific anyway and you've gained no ability to use drivers for multiple architectures side-by-side! Multiarch is a transition that will have a very long tail, and that's perfectly ok. There's certainly no need to rush to convert things to new paths where there isn't a clear and understood benefit. > 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. Yes. For examples of how this can be done, feel free to look at the gdk-pixbuf and glib2.0 patches. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
