svn commit: r352093 - head/x11/startup-notification

[Tijl Coosemans]

On Fri, 25 Apr 2014 11:20:12 +0200 Baptiste Daroussin wrote:
> On Fri, Apr 25, 2014 at 11:13:27AM +0200, Tijl Coosemans wrote:
>> On Fri, 25 Apr 2014 07:38:02 +0000 (UTC) Baptiste Daroussin wrote:
>>> Modified: head/x11/startup-notification/pkg-plist
>>> ==============================================================================
>>> --- head/x11/startup-notification/pkg-plist	Fri Apr 25 07:34:14 2014	(r352092)
>>> +++ head/x11/startup-notification/pkg-plist	Fri Apr 25 07:38:01 2014	(r352093)
>>> @@ -5,9 +5,9 @@ include/startup-notification-1.0/libsn/s
>>>  include/startup-notification-1.0/libsn/sn-util.h
>>>  include/startup-notification-1.0/libsn/sn.h
>>>  lib/libstartup-notification-1.a
>>> -lib/libstartup-notification-1.la
>>>  lib/libstartup-notification-1.so
>>>  lib/libstartup-notification-1.so.0
>>> +lib/libstartup-notification-1.so.0.0.0
>>>  libdata/pkgconfig/libstartup-notification-1.0.pc
>>>  @dirrm include/startup-notification-1.0/libsn
>>>  @dirrm include/startup-notification-1.0
>> 
>> It's probably better to use libtool:keepla here.  There are too many
>> ports that depend on this port with .la files that may refer to
>> libstartup-notification-1.la.
>> 
>> I've been thinking if it would be possible for pkg to register .la files
>> (and their references to other libraries) like it does with .so files.
>> Then you could find out if there are references lurking in other ports
>> with pkg rquery.
> 
> Concerning gnome related ports like this one I'm pretty confident about removing
> the .la as upstream jhbuild continuous integration system expect everything to
> be install without .la, so almost nothing should expect to find the .la here.

The problem is that it was previously there so other .la files now contain
references to it.  For instance on my xfce system:

% grep -Rl libstartup-notification-1.la /usr/local/lib/*
/usr/local/lib/libstartup-notification-1.la
/usr/local/lib/libwnck-1.la
/usr/local/lib/libxfce4kbd-private-2.la
/usr/local/lib/libxfce4ui-1.la
/usr/local/lib/libxfsm-4.6.la
/usr/local/lib/thunarx-2/thunar-uca.la
/usr/local/lib/xfce4/panel/plugins/libactions.la
/usr/local/lib/xfce4/panel/plugins/libapplicationsmenu.la
/usr/local/lib/xfce4/panel/plugins/libclock.la
/usr/local/lib/xfce4/panel/plugins/libdirectorymenu.la
/usr/local/lib/xfce4/panel/plugins/liblauncher.la
/usr/local/lib/xfce4/panel/plugins/libpager.la
/usr/local/lib/xfce4/panel/plugins/libseparator.la
/usr/local/lib/xfce4/panel/plugins/libshowdesktop.la
/usr/local/lib/xfce4/panel/plugins/libsystray.la
/usr/local/lib/xfce4/panel/plugins/libtasklist.la
/usr/local/lib/xfce4/panel/plugins/libwindowmenu.la
/usr/local/lib/xfce4/panel/plugins/libclipman.la
/usr/local/lib/xfce4/panel/plugins/libxfce4dict.la
/usr/local/lib/xfce4/session/splash-engines/libbalou.la
/usr/local/lib/xfce4/session/splash-engines/libmice.la
/usr/local/lib/xfce4/session/splash-engines/libsimple.la

The problem is that when I update x11/startup-notification now these
references go stale.  If I then update a port that links with libwnck-1.la
for instance using libtool, that will be broken because libtool cannot
find libstartup-notification-1.la.

> concerning registering the .la that will be quite complicated because as far as
> I know, no trace of .la is left inside the resulted binaries, but if you think
> about a clever way, I'm not against it :)

No, you need to scan the .la files itself just like you scan .so files.
Think of an .la file as a library on its own.  A package can provide .la
files and it can have other .la files as dependencies.  We're trying to
get rid of these .la dependencies, but it would be nice to have a way to
detect them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-head/attachments/20140425/6fd81ca8/attachment.sig>