[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: shared library -dev package naming proposal


Thanks for your time and feedback. I appreciate it very much.

> You could also suggest a policy for libs to have a libfoo.devname file
> similar to the libfoo.shlibs file but naming the needed -dev
> packages. If that is a good idea or not you have to think about. Just
> a wild idea.

Yes, that's basically what shlibs file is doing for shared libraries.
I was hoping that it was more practical to have a 
Provides: field or a package name that can be linked from 
the shared library package.

Stephen Frost has explained to me that -dev package names
apparently express their API, and their maintainers
can be beaten to whatever when they break, 
and I kind of agree that might even be a good idea,
I would like to drop the idea of unanimously 
requesting packages to name their -dev packages thus way.

From the standpoint of a Debian user, it still stands that 
shared library packages and -dev packages (which has a 
symlink pointing to the shared library package) do not 
have an explicit relationship declared in Debian,
except for the fact that they are often created from the 
same source.

Stephen's points are valid and quite useful 
considering an upstream developer's point of view,
but for random user joe who is trying to find a development
package, one of the following may help him find the right package

1. creating a system-wide list of what -dev package does what.

  -> centrally requires work. Already started in d-shlibs.

2. creating a devlibs file which points to what shared library
  is handled by which -dev package.

  -> requires manual intervention by all developers,
  and utilizes an i-node for all shared library installations.

3. creating a package policy to Provides: a symbollic name
   that can be traced from the shared library package name or
   the shared library soname.

  -> non-invasive if it's done gradually.

> > Okay, currently d-shlibs is using objdump, 
> > and does not recursively look for dependencies.
> >
> > gotom suggested to use ldd, to obtain the full path of 
> > shared libraries, and I do see the limitation with
> > using ldd, as you pointed out illustratively
> > in your example.
> You have to do both. ldd for the full path and then filter that with
> objdump. That is how dpkg-shlibdeps does it if I read the code right.

Thanks for pointing that out.
This knowledge may become useful when ldd output can be converted to
a list of -dev packages.


Reply to: