Bug 203574

$ ldd /usr/bin/lftp:
        liblftp-jobs.so.0 => /usr/lib64/liblftp-jobs.so.0 (0x00002aaaaaad2000)
        liblftp-tasks.so.0 => /usr/lib64/liblftp-tasks.so.0 (0x00002aaaaac38000)
        libreadline.so.5 => /usr/lib64/libreadline.so.5 (0x0000003ec7600000)
        libutil.so.1 => /lib64/libutil.so.1 (0x0000003ece400000)
        libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x0000003ece200000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003ec7400000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003ec6f00000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003ec9a00000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003ec7200000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003ec6d00000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003ec9800000)

- /usr/lib/lib*.so are using
- .la & .a - removed in new spec in RAWHIDE

(In reply to comment #1)
> $ ldd /usr/bin/lftp:
>         liblftp-jobs.so.0 => /usr/lib64/liblftp-jobs.so.0 (0x00002aaaaaad2000)
>         liblftp-tasks.so.0 => /usr/lib64/liblftp-tasks.so.0 
 
> - /usr/lib/lib*.so are using

No they aren't. What is used is liblftp-jobs.so.0, not liblftp-jobs.so
(and it is found using soname, not file name).  liblftp-jobs.so is only
usefull when linking or dlopening.

> - .la & .a - removed in new spec in RAWHIDE

nice.

lrwxrwxrwx 1 root root     21 Aug 23 10:17 /usr/lib64/liblftp-jobs.so ->
liblftp-jobs.so.0.0.0
lrwxrwxrwx 1 root root     21 Aug 23 10:17 /usr/lib64/liblftp-jobs.so.0 ->
liblftp-jobs.so.0.0.0
-rwxr-xr-x 1 root root 348976 Aug 23 10:14 /usr/lib64/liblftp-jobs.so.0.0.0

It's used lliblftp-jobs.so.0.0.0. Liblftp-jobs.so.0 & liblftp-jobs.so are only
symlinks to liblftp-jobs.so.0.0.0.
liblftp-jobs.so.0.0.0's soname is liblftp-jobs.so.0 not liblftp-jobs.so and I
don't see any reason to deleting them.

*** Bug 203264 has been marked as a duplicate of this bug. ***

(In reply to comment #3)

> It's used lliblftp-jobs.so.0.0.0. Liblftp-jobs.so.0 & liblftp-jobs.so are only
> symlinks to liblftp-jobs.so.0.0.0.
> liblftp-jobs.so.0.0.0's soname is liblftp-jobs.so.0 not liblftp-jobs.so and I
> don't see any reason to deleting them.

Not deleting all of them indeed, only
liblftp-jobs.so
The reason is that is may be possible to link against liblftp-jobs if 
liblftp-jobs.so is present, and it is wrong to be able to link against
the main package. It should only be possible to link against a -devel
package. 

If something dlopen liblftp-jobs it is another story.

Forgot to say that it is a must item here:

http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
- MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1),
then library files that end in .so (without suffix) must go in a -devel package.

(In reply to comment #6)
> Forgot to say that it is a must item here:
> 
> http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
> - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1),
> then library files that end in .so (without suffix) must go in a -devel package.

 -> there are no library files without suffix !!

There was (or still is) a reason to make a link from .so to suffixd library. If
I will not find any good reason, I'll make a fix. 

>  -> there are no library files without suffix !!

There are:
/usr/lib/liblftp-jobs.so
/usr/lib/liblftp-tasks.so

(In reply to comment #8)
> There was (or still is) a reason to make a link from .so to suffixd library. If
> I will not find any good reason, I'll make a fix. 

It is possible that something dlopen them. In that case
the .so may be needed. But if it is the case this .so shouldn't
be in %_libdir, but in a subdir, like 

/usr/lib/lftp/3.5.1/liblftp-network.so
/usr/lib/lftp/3.5.1/liblftp-pty.so
....
and so on which are certainly dlopend plugins and are rightly
in a %_libdir subdirectory. 

Now this is just not true. 
There is nothing wrong with being able to link against a non-devel package.

For me it is the objective of the MUST I quoted above.
And it is certainly true in fedora extras.
And it should, in my opinion, be pursued as a goal for
consistency and more importantly build reproducibility.
If a non-devel package bring in files that may be linked
against, then it may appear in the buildroot, be detected by
the package being built and linked against in an unpredictable
way (that is, although it wasn't a -devel BuildRequire).

Things are not always so easy. Blindly splitting existing packages can cause
considerable ripple effects via dependencies that need to be updated. And it 
is very silly to create -devel packages that contain almost nothing, like a 
single .pc file.

(In reply to comment #13)
> Things are not always so easy. Blindly splitting existing packages can cause
> considerable ripple effects via dependencies that need to be updated. And it 
> is very silly to create -devel packages that contain almost nothing, like a 
> single .pc file.

There are very few packages that aren't split nowadays, and on
my system (a typical development system) I only had to fill 31
bugreports, 29 for core and 2 for extras. In fact all the 
package that depend on another -devel packages should allready
be split (I found only 2 like that, with missing requires on 
another -devel package).

If it is a package heavily buildrequired, it is possible to first have
a provide for the -devel package in the main package, and later
split for real when the dependent packages have been corrected.

And it isn't possible to have a package only with .pc file, there
is also something to link against. What is possible is to have
a package only with .so. But in that case it means, most of the time,
that the .so shouldn't be shipped at all, since headers are missing
(exception could be fortran packages but there are none in core).

Anyway -devel packages should never been blindly created, since
there may be dlopened shared libs, so great care should be taken.

Anything new? Can't the .so be simply removed?

The package has been split, but wrongly. The shared libs shouldn't
be in the devel subpackage, only the .so symlinks. There should
be:

%files -f %{name}.lang
........
%{_libdir}/liblftp-jobs.so.*
%{_libdir}/liblftp-tasks.so.*
.....

%files devel
%defattr(-,root,root,-)
%{_libdir}/liblftp-jobs.so
%{_libdir}/liblftp-tasks.so

Moreover, the devel package should

Requires: %{name} = %{version}-%{release}


As a side note, I still think that the %{_libdir}/liblftp-jobs.so
%{_libdir}/liblftp-tasks.so files shouldn't be shipped.

liblftp-jobs.so.0 is not devel library!!!!!
Not only it is wrong but now the whole lftp is unusable now:
# lftp
lftp: error while loading shared libraries: liblftp-jobs.so.0: cannot open 
shared object file: No such file or directory

And with this dependency the devel package is always requred.
The only user of this library is lftp (for years maybe).

What is the point of devel package if there are no headers to use it?
If the running requires the library it is not for devel. Why not just remove "--
disable-static" and stop all this...

P.S. I don't know how yum missed this dependency, but it is a fact.

(In reply to comment #17)
> liblftp-jobs.so.0 is not devel library!!!!!
> Not only it is wrong but now the whole lftp is unusable now:
> # lftp
> lftp: error while loading shared libraries: liblftp-jobs.so.0: cannot open 
> shared object file: No such file or directory

This is certainly a bug in rpm or yum, I have seen some messages
flowing on the list about yum, maybe this is related. I had other
missing dependencies.

> And with this dependency the devel package is always requred.
> The only user of this library is lftp (for years maybe).
> 
> What is the point of devel package if there are no headers to use it?
> If the running requires the library it is not for devel. Why not just remove "--
> disable-static" and stop all this...

That has already been done. The devel package would only contain
%{_libdir}/liblftp-jobs.so
%{_libdir}/liblftp-tasks.so
and agree with you that this devel package is useless.

(In reply to comment #18)

> > And with this dependency the devel package is always requred.
> > The only user of this library is lftp (for years maybe).
> > 
> > What is the point of devel package if there are no headers to use it?
> > If the running requires the library it is not for devel. Why not just remove "--
> > disable-static" and stop all this...

In fact, after rereading this I don't understand your point. Do you 
want a static library to be shipped with lftp? I don't think this would be
of any use.

(In reply to comment #19)
> In fact, after rereading this I don't understand your point. Do you 
> want a static library to be shipped with lftp? I don't think this would be
> of any use.
> 
> 

Sorry, I didn't compiled lftp myself for long time and back then there was no 
such libraries IIRC. Infact I didn't used and "--with-modules". They are all 
included in lftp.
If lftp didn't create liblftp-jobs.so.0* and liblftp-tasks.so.0* would be 
better, but anyway they exist and my point was: If lftp depends on those libs - 
let them be in the lftp package, not separated. But now I see that this was a 
mistake to remove "*.so.0" from lftp.
So lftp-devel will be package with only two links in it. Funny. It could be an 
exception to include them in lftp package, but developers decide.
Anyway, for me it looks like I now need lftp-devel to use lftp. I hope it will 
not be needed for the next lftp release.

(In reply to comment #20)

> let them be in the lftp package, not separated. But now I see that this was a 
> mistake to remove "*.so.0" from lftp.

Indeed, it is a packaging mistake.

> So lftp-devel will be package with only two links in it. Funny. It could be an 
> exception to include them in lftp package, but developers decide.

I don't think so. Without headers those symlinks aren't of any use anyway,
in my opinion they should not be shipped in fedora.

> Anyway, for me it looks like I now need lftp-devel to use lftp. I hope it will 
> not be needed for the next lftp release.

Hopefully this will be fixed.

This is still occurring on Apr 15th.

I do not have lftp or lftp-devel installed yet yum keeps trying to update lftp
and confilicts with lfpt-devel.

However, lftp-devl is not in the repo.

If this is a yum problem it could / does whack an install and become a release
blocker.

Darwin

I use rawhide release and lftp has been succesfuly updated without devel package
by lftp-3.5.10-3.fc7.

Try to remove lftp and lftp-devel package and install lftp again.

Closing bug in WONTFIX state. If any consideration, let me know by reopening
this bug.

Lftp depends on those libraries. If we move libs to lftp-devel, it will be
package with only two links in it. After resolving dependecies, this bug will be
reopened and closed as CLOSED RAWHIDE.

How does lftp depend on those symlinks? the lftp libraries seems
to be internal convenience libs, so it seems to me than the
.so symlinks shouldn't be shipped at all. What would break in that case?
Of course it is not for F7, but for F8 I think it would be right
to remove the symlinks.

For F-8 removed.