On Wed, 25 Jun 2003, Stefan van der Eijk wrote:
> >> >No, the one in /usr/lib is a link to the one in /lib, but they are
> >> >not the same files, but that isn't relevant. But why is there no
> >> >libdb-3.so file (if we are going to go with the naming used for
> >> >libdb40).
>
> >> >>What's the problem exactly?
>
> >> >The fact that the versioned library file doesn't have it's version
> >> >trailing the .so.
>
> >> Yes.
>
> > So what should happen if a package has a build requirement on a specific
> > version of a library (e.g. libfoo.so.1.0.7)?
> Then you'll need to specify this specific BuildRequires in the .spec file,
> with the package name.
>
> BuildRequires: libfoo-deve >=1.0.7 or something like that.
I suppose this should only happen like your example with a > or >=.
> > Or is this impossible unless a versioning scheme like with db3 & db4 is
> > used? If it should work you're right to want different dependency names.
> We're seeing that more and more of these dependencies have version numbers
> in them for the major part. Good example are the glib1.2-devel and
> glib2-devel packages.
Yes, but here libglib-2.0 is a different library, no versioning is done on
the -x.y part. Except that there is no libglib-1.2.so but instead only a
libglib.so. It's all consistent though, a library provides a file where
the SONAME matches the filename, and zero or more symlinks for linking
against it during build-time. Maybe this has been suggested before, but
what's against naming the provides and requires for a library libfoo.so
"libfoo-devel" so if you have libfoo-1.2.so you get "libfoo-1.2-devel"?
libdb4.0-devel should then get (amongst others)
provides: libdb-4.0-devel libdb-4-devel libdb-devel
> >> >Stefan, I think the problem isn't the naming of the requirements,
>
> >> Well, you can't disagree that using the ".so" is at least confusing.
> >> It's very difficult to tell where it came from.
>
> >> If we would change the naming, then even _if_ packaging is incorrect,
> >> it wouldn't fool the system --> and that's one of my main motivations
> >> to change the naming.
>
> >> >it's the method. We shouldn't be chopping off the bit that follows
> >> > .so, we should be finding the file that links to the library listed.
>
> >> I don't follow you here...
>
> > For a regular dependendy to libdb-4.0.so one might expect a -devel
> > dependency on libdb-4.so, or even libdb.so. Note that libtool doesn't
> > get this right either (or does it use the same code?), judging from
> > /usr/lib/libdb-4.0.la:
> > library_names='libdb-4.0.so libdb-4.0.so libdb-4.0.so'
> >
> > At least, I would expect it to be:
> > library_names='libdb-4.0.so libdb-4.so libdb.so'
>
> Yes, this is confusing. And I don't intend to these inconsitancies :-) As
> unix is consistanly inconsistant.
>
> I'm aiming to make the -devel dependencies smart enough that it won't be
> fooled by these inconsitancies. By introducing a different naming scheme
> the confusion is over...
So you want indeed distinguish between a -ldb, a -ldb-4, and a -ldb-4.0?
These should all get different dependencies so you get the correct
behavior if/when a db4.2 or db5.0 gets released.
Christiaan
