Bug 203574 - remove liblftp-jobs.so and liblftp-tasks.so for internal libraries
remove liblftp-jobs.so and liblftp-tasks.so for internal libraries
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lftp (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Maros Barabas
: Reopened
: 203264 (view as bug list)
Depends On:
Blocks: 225984
  Show dependency treegraph
 
Reported: 2006-08-22 11:03 EDT by Patrice Dumas
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-17 09:03:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrice Dumas 2006-08-22 11:03:50 EDT
Description of problem:

the .a and /usr/lib/lib*.so should be in a devel package.
Or not shipped at all since there are no headers.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Maros Barabas 2006-08-23 04:25:22 EDT
$ 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
Comment 2 Patrice Dumas 2006-08-23 04:38:59 EDT
(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.
Comment 3 Maros Barabas 2006-08-23 05:01:23 EDT
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.
Comment 4 Maros Barabas 2006-08-23 05:03:30 EDT
*** Bug 203264 has been marked as a duplicate of this bug. ***
Comment 5 Patrice Dumas 2006-08-23 05:59:03 EDT
(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.
Comment 6 Patrice Dumas 2006-08-23 06:11:58 EDT
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.
Comment 7 Maros Barabas 2006-08-23 07:49:09 EDT
(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 !!
Comment 8 Maros Barabas 2006-08-23 07:54:20 EDT
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. 
Comment 9 Patrice Dumas 2006-08-23 08:02:39 EDT
>  -> there are no library files without suffix !!

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

Comment 10 Patrice Dumas 2006-08-23 08:04:57 EDT
(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. 


Comment 11 Matthias Clasen 2006-08-23 11:26:41 EDT
Now this is just not true. 
There is nothing wrong with being able to link against a non-devel package.
Comment 12 Patrice Dumas 2006-08-23 11:44:14 EDT
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).
Comment 13 Matthias Clasen 2006-08-23 15:55:32 EDT
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.
Comment 14 Patrice Dumas 2006-08-23 17:43:48 EDT
(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.
Comment 15 Patrice Dumas 2006-11-17 10:10:30 EST
Anything new? Can't the .so be simply removed?
Comment 16 Patrice Dumas 2007-04-07 08:50:16 EDT
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.
Comment 17 Boyan Anastasov 2007-04-08 05:02:07 EDT
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.
Comment 18 Patrice Dumas 2007-04-08 05:11:01 EDT
(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.

Comment 19 Patrice Dumas 2007-04-08 05:14:36 EDT
(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.

Comment 20 Boyan Anastasov 2007-04-08 06:17:53 EDT
(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.
Comment 21 Patrice Dumas 2007-04-09 06:38:59 EDT
(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.
Comment 22 Darwin H. Webb 2007-04-15 10:33:16 EDT
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
Comment 23 Maros Barabas 2007-04-16 02:51:50 EDT
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.
Comment 24 Maros Barabas 2007-05-22 08:08:31 EDT
Closing bug in WONTFIX state. If any consideration, let me know by reopening
this bug.
Comment 25 Maros Barabas 2007-05-22 08:17:52 EDT
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.
Comment 26 Patrice Dumas 2007-05-22 13:18:33 EDT
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.
Comment 27 Maros Barabas 2007-09-17 09:03:03 EDT
For F-8 removed.

Note You need to log in before you can comment on or make changes to this bug.