xfce 4.2.1 packages available

[Michael Schwendt]

On Mon, 21 Mar 2005 14:23:59 +0100, Ralf Corsepius wrote:

> > It does matter. If .la files for private plugins are just a byproduct of
> > using libtool, there are useless and only increase the file count.
> Wrong. Though, they are not necessary on linux in most situations, but
> they are needed by _libtool_ on other systems as part of the libtool-
> API.
> 
> Get yourself a Sun and you will experience that your statement is wrong.

I wonder what the relevance of that is in this discussion. I'm not
questioning usefulness of libtool or libtool archives on other platforms.

> >  Plugin
> > DSOs cannot be used by external programs unless there is an API actually.
> > 
> > If you went on with your rationale, you would also judge that the .a
> > files are needed because they belong to the package's API, regardless
> > of whether they are located in private plugin directories.
> Right - The point is to distinguish whether these *.a are private or are
> part of the API.
> 
> The purpose of plugins and shared-libs however is sharing them, so you
> as a package have no possibility to know who might do what with them.

Static archives in a plugins directory? Show where/how/when they are used
or could be used, and then they can be included. Else they only increase
the size of the binary packages with superfluous files.

> > > This applies to shared libraries as well as to plugins - They are
> > > supposed to be "shared" between applications.
> > 
> > Our Linux's run-time and build-time linkers don't need the libtool
> > archives. Often the added inter-library dependency information in these
> > files require unneeded explicit package dependencies, too.
>
> Whether you like it or not, these dependencies exist.

At run-time, yes. At build-time, libtool only increases the dependencies
on many -devel packages which are not needed for the linking step.

> libtool only makes
> these dependencies explicit -

And with that you need to make them explicit in a package spec file, too,
which is not good. If a program links against libfoo, it needs
libfoo-devel at built-time (and any additional packages for include files
it chainloads) [*], but not other -devel packages libfoo might be _linked_
against. Those are run-time dependencies.

[*] For that I would prefer pkgconfig based dependencies.

> However there exist broken versions of
> libtool and mal-configured packages which produce broken *.la's.

Yes, that's another story. ;)

A story like broken pkgconfig templates which pollute LDFLAGS with
linker options that insert standard library search paths in front of
user-defined search paths.

Or KDE which includes an incorrectly configured ltdl which does not know
about the .so file name extension for shared objects and hence is limited
to .la files.