Bug 170602

Sorry, of course
BR: libacl-devel
should stay. 

However, without removing the references to -lacl in it's .la files, you'd need
to add
Requires: libacl-devel
to kdelibs-devel.

FYI, looks like 
-devel: Requires: libacl-devel
as added to kdelibs-3.4.91-2.  So that part is a little better.

Unfortunately, due to the recent removal of libjpeg.la, kdelibs needs to be
rebuilt (or you could remove all libjpeg references as I suggested in comment #1).

this workaround will be included in next KDE-3.5-rc1. Many thanks for your
reports

it's now fixed in kdelibs-3.5.0-0.1.rc1. Many thanks for your report.

Ngo, looks like you've just did a rebuild (for kde-3.5rc1), but didn't remove
any of the extra crud from kdelibs' libtool archives (/usr/lib/lib*.la).   If
you did, you could drop all those extra Req's in kdelibs-devel, including:
Requires: libart_lgpl-devel
Requires: libxslt-devel
Requires: libjpeg-devel
Requires: zlib-devel
Requires: openssl-devel
Requires: bzip2-devel
Requires: libtiff-devel
Requires: libidn-devel
Requires: libacl-devel
Requires: fam-devel
Requires: pcre-devel

Was that intentional?

yes, all above extra Reqs are not needed anymore and will be removed in next
kdelibs rebuild. Many thanks for your report.

Still have build problems because of .la dependencies:

/bin/sh ../../libtool --silent --mode=link --tag=CXX g++  -Wnon-virtual-dtor
-Wno-long-long -Wundef -Wall -W -Wpointer-arith -Wwrite-strings -ansi
-D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts
-O2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=nocona -Wformat-security
-Wmissing-format-attribute -fno-check-new -fno-common -fexceptions    -o
kio_ksvn.la -rpath /usr/lib64/kde3 -avoid-version -module
-L/usr/lib64/qt-3.3/lib -L/usr/lib64  -avoid-version -module -no-undefined
-Wl,--no-undefined -Wl,--allow-shlib-undefined   kiosvn.lo kiolistener.lo
../../src/svnfrontend/fronthelpers/libsvnfrontend_helpers.la
../../src/svncpp/libsvnwrapper.la ../../src/helpers/libhelper.la -lkio -lkparts
-lapr-1  -lpthread -ldl  -laprutil-1 -lldap -llber -ldb-4.3 -lexpat -lneon
-L/usr/lib64 -lsvn_client-1 -lsvn_wc-1 -lsvn_ra-1 -lsvn_delta-1 -lsvn_subr-1 -lkio
/usr/bin/ld: cannot find -lacl

/usr/lib64/libkio.la:dependency_libs=' -L/usr/kerberos/lib64
-L/usr/lib64/qt-3.3/lib -L/usr/lib64 /usr/lib64/libkdeui.la
/usr/lib64/libkdesu.la /usr/lib64/libkwalletclient.la /usr/lib64/libkdecore.la
/usr/lib64/libDCOP.la -ldl -lresolv -lutil   /usr/lib64/libkdefx.la -lqt-mt 
-lXext -lX11 -lSM -lICE -lpthread -lXrender -lz  -lacl -lattr'

So, I guess either remove -lacl from the .la or add Requires: acl-devel to
kdelibs-devel, whichever is appropriate.  Looks true for -lattr as well.

Oops, libacl-devel and libattr-devel.

This is with kdelibs-3.5.0-1.1

Yep, looks like Ngo grabbed all the .la scrubbing bits, except for -lacl (per
near the top of my initial comment here):
sed -e -i 's|-lacl||' $RPM_BUILD_ROOT%{_libdir}/lib*.la

Looks like -lattr might try to sneak in too, so you might as well also:
sed -e -i 's|-lattr||' $RPM_BUILD_ROOT%{_libdir}/lib*.la

To be fully paranoid,

# libacl/libattr
sed -i -e "s@-lacl@@g" $RPM_BUILD_ROOT%{_libdir}/lib*.la
sed -i -e "s@%{_libdir}/libacl.la@@g" $RPM_BUILD_ROOT%{_libdir}/lib*.la
sed -i -e "s@/%{_lib}/libacl.la@@g" $RPM_BUILD_ROOT%{_libdir}/lib*.la
sed -i -e "s@-lattr@@g" $RPM_BUILD_ROOT%{_libdir}/lib*.la
sed -i -e "s@%{_libdir}/libattr.la@@g" $RPM_BUILD_ROOT%{_libdir}/lib*.la
sed -i -e "s@/%{_lib}/libattr.la@@g" $RPM_BUILD_ROOT%{_libdir}/lib*.la

I now add the requires on devel subpackage back in next kdelibs build. The hack
(removing the references fro *.la) is risky. The correct way is
to get rid of *.la from KDE. but it seems to need more works and should be done
in kde upstream!

That's too bad... kde-redhat has been removing all those extraneous library
references from .la files for quite a long time, without adverse affects.

Reopened... looks like we're seeing the dangling references to libacl in fc4's
kdelibs build now.  (I tried to check kdelibs's FC-4 branch in cvs, but it's
still at kdelibs-3.4.1-0.fc4.1?).

Now, are you *sure* you'd rather not simply remove these pesky .la file references?

Another one found: 
# alsa-lib/asound 
sed -i -e "s@-lasound@@g" $RPM_BUILD_ROOT%{_libdir}/lib*.la 
 
If not fixed, should add to -devel: 
Requires: alsa-lib-devel 
 
(you/rawhide users probably haven't seen this because currently arts-devel 
Req's alsa-lib-devel, but that's a separate issue) 
 

Arg, now the libidn maintainer is using the fact the KDE's .la files include
references to libidn.la as an excuse not to omit libidn.la from packaging (see
bug #172639).

WARNING: due to rpm's new feature of automatic creation/extraction of libtool
dependancies, this will result in many needless extraneous dependancies here if
it's not cleaned up as has been suggested.  See also bug #193134.

Rex, i don't want to remove the *.la files from kde packages, because it will
break KDE. It needs to be fixed from KDE upstream. I don't like the hack in the
spec file to get rid of the references from the non-KDE packages. The better way
to do that, the non-KDE packages should not include the *.la files, and it
should be done for FC6.

>  it will break KDE

I'll say it one more time (see comment #12), then shut-up...  (:  kde-redhat
packages have been using this method of removing extraneous .la file
dependancies *for years*.  And, guess what?  It works.  No breakage.  Please,
why don't you try it before claiming otherwise.

I agree this is an upstream issue, but I'd argue it's not KDE's problem, it's
libtool's.  As it is, KDE can't simply remove all .la files, because in some
cicrcumstances, on some platforms, they're required for proper functionality. 
To address this problem fully/properly, libtool needs to be able to make
distinctions between library .la files and other .la files (ie, plugins,
loadable modules, etc...), and/or make dictinctions between the shared-lib and
static-lib case.

Until the proper fix comes to fruition (if ever), there are some relatively
simple workarounds like 
* generally omitting %{_libdir}/lib*.la files from -devel packaging
* when/if %_libdir}/lib.la files cannot be omitted, prudently prune the
extraneous bits.

> The better way to do that, the non-KDE packages should not include the *.la 
> files, and it should be done for FC6.

Better than doing nothing, but still involves dependancy bloat.  All this
accomplishes is that it replaces .la file references to /usr/lib/libfoo.la with
-lfoo
kdelibs-devel's dependancy on libfoo-devel (or whereever libfoo.so lives) is
still bogus.