xfce 4.2.1 packages available

[Kevin Fenzi]

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

>>>>> "Michael" == Michael Schwendt <bugs.michael at gmx.net> writes:

>> Does that sound reasonable?
>> 
>> If so, I will commit my xfprint and xffm specs with ldconfig
>> removed.

Michael> I don't care that much that I feel the need to try to
Michael> convince you. I've made my obligatory comments on static
Michael> archives in plugins directories, and you are free to
Michael> disagree.

Well, I don't much care, I just don't want to break anything for
people who might use those. 

Michael> The .a files are really just the .so libraries in another
Michael> form for static linking. They are not needed at run-time,
Michael> because the .so plugins are loaded dynamically, the static
Michael> archives in the plugins directories are useless and not
Michael> needed, and your packages don't provide an API for them with
Michael> which the .a versions of the plugins could be used.

Michael> I stick to my view that both .a and .la files should not be
Michael> included in the plugins directories. Certainly the static
Michael> archives should be deleted as they only increase package size
Michael> regardless of how small they might be. It will happen again
Michael> in the future that either me (or somebody else) will point
Michael> out that static archives in plugin directories are not
Michael> needed.

I have asked upsteam on the xfce-dev list to see if anyone knows
anyone having any use at all for the .a or .la files. If not, I asked
if they could remove them as part of the regular build process/not
install them. Will let everyone know what I find out. 

Michael> [xffm package]

Michael> * In there, I don't see any static archives in the plugins
Michael> directory and not in the %_libdir/xfce4/xffm sub-directory
Michael> either.

Michael> * But I see lots of *.so links in /usr/lib, which are usually
Michael> only needed at build-time and therefore moved into -devel
Michael> packages. In case these links are loaded at run-time, the
Michael> application ought to load the versioned DSOs instead,
Michael> e.g. libxffm_actions.so.1 instead of libxffm_actions.so

Ah, an excellent point. 
Looking at the xffm build it looks to me like those /usr/lib/ files
are used by xffm when it's compiling itself. Its possible there are
people using those to develop more xffm plugins, etc. 

So, those should be split out into a -devel rpm most likely. 
Should we do that now given that the xffm package in fc3 4.0.6 package
included them? I would guess anyone using them to develop would be
able to see the new xffm-devel package. 

Michael> * Which package includes the directory /usr/lib/xfce4/xffm/?

xffm should. It includes the files in that directory. Does it need to
explicitly own that directory as well?

kevin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCP2gG3imCezTjY0ERAhi4AJ9SgvqrNN8b3I4Rck4lJycMnL+zsQCglI5r
e6/LE+7tG+bfAe4hYJlCd4I=
=JR5y
-----END PGP SIGNATURE-----