Is panel plugins integration broken at the moment?

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fabian Nowak wrote:
> Am Samstag, den 29.10.2005, 04:01 -0700 schrieb Brian J. Tarricone:
>>
>>Fabian Nowak wrote:
>>
>>>- no other desktop systems use libexec,
>>
>>Totally incorrect:
>>
>>$ ls /usr/libexec/g*
>>/usr/libexec/gconf-sanity-check-2*   /usr/libexec/gnome-keyring-ask*
>>/usr/libexec/gconfd-2*               /usr/libexec/gnome-pdf-viewer*
>>/usr/libexec/gdict-applet*           /usr/libexec/gnome-pty-helper*
>>/usr/libexec/gdmaskpass*             /usr/libexec/gnome-vfs-daemon*
>>/usr/libexec/gdmopen*                /usr/libexec/gnome_segv2*
>>/usr/libexec/gdmtranslate*           /usr/libexec/gthumb-catalog-view*
>>/usr/libexec/ggv-postscript-viewer*  /usr/libexec/gthumb-image-viewer*
>>
>>Looks like gnome uses it for quite a few things, and I don't have the
>>entirety of gnome installed.
> 
> well, most of my software is prepackaged as is in most distributions
> which are widely spread. i do neither have /usr/libexec nor any other
> programs in /usr/local/libexec despite from the ones in the subdirectory
> xfce4.

So then what are you complaining about?  If you want packages that you
compile and install from source to behave the same way as your distro's
packages, then you have to provide the same options to configure that
your distro does.

>>>- adding $prefix/lib to ld.so.conf is already necessary for even the old
>>>  panel,
>>
>>Well, if you install it to a non-system location, of course it is.  What
>>else would you expect?
> 
> from a user's point of view, i expect it to install to where my
> environment varaibles do already point or at least to ask me if i would
> like to have changed that. don't forget, xfce is not only run by power
> users.

Your environment variables do not, in any way, determine where Xfce gets
installed.  The options you give to configure do.  If these so-called
non-power-users can't handle that, then they should wait for their
distro to package it in whatever manner fits their distro best.  Or, if
they insist on doing something "advanced" with their system, they can
*gasp* try to learn something.

>>>- installation instructions on xfce-goodies wiki site already contain 
>>>  the third point and would be blown having another sentebnce saying "if
>>>  you run panel 4.4, which can be found out by typing [...] add 
>>>  libexec",
>>
>>Irrelevant and unnecessary.  See my first point.
>>
>>
>>>- some documentations say libexec was deprecated,
>>
>>Please provide the URL of an authoritative source that states this.
>>Even then, this isn't really relevant.  If a distro packager (or user)
>>wants to, they can simply provide --libexecdir= to configure.
> 
> i had expected that you were able to remember this thread and to
> investigate the links yourself, but here they are:
> http://www.pathname.com/fhs/pub/fhs-2.3.html
> http://www.humbug.org.au/talks/fhs/usr.html

I had remembered from last time, but the URL provided didn't say
anything about libexec being deprecated.  At any rate, the first URL you
just gave me doesn't mention libexec at all (which doesn't mean you
can't have one, just that it's not specified in the FHS).

The second URL you provide describes libexec in the exact manner that
the panel is currently using it, and says nothing about it being deprecated.

> "> Should we change some of these to /usr/libexec?
> 
> I don't think so. Both FHS 2.1 (referenced by the current Policy) and
> FHS 2.3 (the latest FHS version) mandate /usr/lib (or a subdirectory)
> for internal binaries." @
> http://lists.debian.org/debian-devel/2005/05/msg00405.html

Someone saying something in a mailing list post does not an
authoritative source make.  I can't seem to find a non-PDF copy of v2.1
of the FHS with some quick googling, and to be honest, this problem
isn't important enough to me to waste any more time digging for it.

Regardless, if FHS 2.1 does indeed deprecate libexec, I still don't
particularly care.  Again, if you don't like libexec, pass
- --libexecdir=$prefix/lib to configure.  The power is entirely in your
hands to do this, and if your chosen distro agrees with you that libexec
is deprecated, likely they'll do this for you when creating official
packages...  when this *development-grade* software is actually released.

>>>i suggest switching to $prefix/lib for the panel plugins location for
>>>ease of use which is one of Xfce's main principles. this would also
>>>decrease the amount of "the plugin ... is not shown" mails on the
>>>mailing lists.
>>>i know that all ported plugins would need to be changed in their
>>>configuration files for another configuration path and don't mind doing
>>>that for my plugins and would also do that for other plugins where
>>>necessary.
>>
>>Sorry, but quite frankly you've misinterpreted the problem and don't
>>have a clue as to what you're talking about.
> 
> ahem, i've not tried to interprete the problem, but to re-talk/-open it
> and have you or jasper find a solution.

No, you tried to interpret the problem and tell us why what we are doing
is wrong, and in the process made no sense.

>>At any rate, I just looked at 'libtool --mode=link --help', and I think
>>the solution here is to add "-R$(libdir)" to LDFLAGS in our Makefile.am.
>> I'm not 100% sure if this needs to be done for the external plugins
>>themselves, or for libxfce4panel, or both.  That should hardcode a
>>libdir in the executable itself, so it'll search in the right place
>>regardless of ld.so.conf or LD_LIBRARY_PATH (but should still fall back
>>on these if it can't find the library).
>  
> actually, this answer was what i hoped for - try to investigate how to
> circumvent this problem.

Then why write a long email telling us we are doing things incorrectly?
 Why not just say "hey, has anyone looked into this problem?" and be
done with it?  (Yes, these are rhetorical questions.)

Anyway, unless you have anything useful to add to the *actual problem*,
such as testing the LDFLAGS additions I suggested above, and/or posting
a patch, this thread needs to die.

	-brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDY2TZ6XyW6VEeAnsRApeLAKCefUJbimePZ3fEBl+bRMLaG+yXMACePQEh
Vf9SiJs11d4MciDIVdbzeXo=
=OJ1q
-----END PGP SIGNATURE-----