Rob Browning <r...@defaultvalue.org> writes:
> Andreas Rottmann <a.rottm...@gmx.at> writes:
>
>> reassign 625187 g-wrap
>> thanks
>>
>> Lucas Nussbaum <lu...@lucas-nussbaum.net> writes:
>>
>>> Source: guile-gnome-platform
>>> Version: 2.16.1-5
>>> Severity: serious
>>> Tags: wheezy sid
>>> User: debian...@lists.debian.org
>>> Usertags: qa-ftbfs-20110502 qa-ftbfs
>>> Justification: FTBFS on amd64
>>>
>> This is actually a bug in guile-1.8, which completely removed the .la
>> files, among them /usr/lib/libguile.la, even though g-wrap still
>> referenced them:
>
> I was told that according to policy for wheezy, the .la files are
> supposed to be removed. Is that wrong?
>
That's the goal, but immediate removal is not always warranted (from
Policy 10.2):
Packages that use libtool to create and install their shared libraries
install a file containing additional metadata (ending in .la)
alongside the library. For public libraries intended for use by other
packages, these files normally should not be included in the Debian
package, since the information they include is not necessary to link
with the shared library on Debian and can add unnecessary additional
dependencies to other programs or libraries.[79] If the .la file is
required for that library (if, for instance, it's loaded via libltdl
in a way that requires that meta-information), the dependency_libs
setting in the .la file should normally be set to the empty string. If
the shared library development package has historically included the
.la, it must be retained in the development package (with
dependency_libs emptied) until all libraries that depend on it have
removed or emptied dependency_libs in their .la files to prevent
linking with those other libraries using libtool from failing.
So the correct thing for guile-1.8 would have been to empty the
dependency_libs variable in the installed .la file(s), since there are
still packages (g-wrap, and others, see below) that reference the .la
file. However, due to the mentioned bug in the script scanning the
archive for unneeded .la files, the bug report you received for
guile-1.8 (#621240) wrongly indicated that the .la files in
guile-1.8-dev can just be removed:
In most cases, the .la file(s) can simply be removed as the process
behind this MBF has already identified that there are no further
dependencies using the .la file.
AFAICS, guile-1.6 received no .la removal bug, but, unless there are
really packages build-depending on guile-1.6 which install .la files
referencing libguile.la, this bug should have been filed on guile-1.6
instead. The current scan result show this line regarding Guile:
guile-1.6: dependency_libs depended-on (g-wrap gnucash
guile-gnome-platform guile-pg xchat-guile)
So it might be the case that the .la file removal in guile-1.8 breaks
any of the mentioned packages. For g-wrap and guile-gnome-platform, I
can (and will) take care of it without needing you to take any action,
but in case you (or anyone else) discovers FTBFSs in one of gnucash,
guile-pg or xchat-guile because of the missing libguile.la, either the
maintainers of these packages need to take action soonish (clearing
dependency_libs or removing the .la files altogether), or you have to
put libguile.la back, with emptied dependency_libs.
> Also note that 1.8.8+1-{1,2} still had the .so files that Guile tries to
> dlopen() in guile-1.8-dev. So for those versions, unless guile-1.8-dev
> was installed, operations like (use-modules (srfi srfi-13)) would fail.
> For -3, I moved them to guile-1.8-libs, which should fix the problem.
>
Good to know.
Cheers, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
