Shared library packaging question
Dear specialists,
I need more help. Specifically, I am going to ask 3 questions.
My debian directory is still messed up, as it has been from the beginning:
either the automatic scripts are not ready to assist in generating a
shared-library
package, or I used them in wrong way.
Here my control file :
---
Source: lmfit
Priority: extra
Maintainer: Joachim Wuttke j.wut...@fz-juelich.de
Build-Depends: debhelper (= 7), autotools-dev
Standards-Version: 3.8.4
Section: libs
Homepage: http://messen-und-deuten.de/lmfit/lmfit.html
Package: lmfit-dev
Section: libdevel
Architecture: any
Depends: lmfit (= ${binary:Version}), ${misc:Depends}
Description: Development files for Levenberg-Marquardt library lmfit
A self-contained implementation of the Levenberg-Marquardt algorithm.
Routine lmmin determines a parameter vector p that minimizes the Euclidean
norm of a vectorial function v(p). The most important application is curve
fitting: to approximate data y(t) by a function f(t;p), routine lmfit
minimizes the norm of the residual vector v = y(t) - f(t;p).
.
This package contains the include file lmmin.h and some application examples.
Package: lmfit3
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Least-squares minimization and curve fitting
A self-contained implementation of the Levenberg-Marquardt algorithm.
Routine lmmin determines a parameter vector p that minimizes the Euclidean
norm of a vectorial function v(p). The most important application is curve
fitting: to approximate data y(t) by a function f(t;p), routine lmfit
minimizes the norm of the residual vector v = y(t) - f(t;p).
.
This package contains the shared library and the man page lmfit(3).
---
Stanislav suggested I create an additional doc package. Given the small
size of the entire project, I tend to think it's better not to inflate the
packaging
overhead and to leave the examples in the dev package.
Question 1:
Is that permissible, or absolutely forbidden by some rule ?
Stanislav suggested the package name lmfit0. By now, however,
I succeeded in instructing autotools to generate the correct shared
library version number so.3.0.2; therefore, it's lmfit3.
Now I need to hand-edit the install files.
Seems straightforward for lmfit3.install:
---
usr/lib/lib*.a
usr/lib/lib*.so
usr/lib/*.la
---
Less trivially, lmfit-dev.install should install the following:
lib/lmmin.h to prefix/include/lmmin.h
doc/lmfit.3 to prefix/share/man/man3
demo/* to ?
Question 2:
Where should the demo sources be installed to ?
Question 3:
Is it possible to write an install file such that the source directory
(e.g. lib) is different from the destination directory (include) ?
Or do I need to first reorganize my source directories ?
Thanks in advance, Joachim
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/eecf718003702b4f89104e3dbaa0ad030f93cd6...@mbx-cluster01.ad.fz-juelich.de
RE: Shared library packaging question
One more question (which possibly elucidates my previous questions): The upstream project is structured as follows: lmfit/configure.ac lmfit/Makefile.am # ... and all the resulting autotools stuff lmfit/lib/ # contains library sources and the include file lmmin.h lmfit/demo/ # contains application examples So, at present, by running the usual configure; make; make install sequence, one gets a working library installation plus working demo executables. Do I have to break that up before I can properly set up a shared-library package and a devdoc package ? What's the easiest way of reorganizing the upstream directory in a way that is convenient both for Debian packaging and for conventional tgz distribution ? - Joachim Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/eecf718003702b4f89104e3dbaa0ad030f93cd6...@mbx-cluster01.ad.fz-juelich.de
Re: Shared library packaging question
On Sat, Mar 27, 2010 at 06:35:42PM +0100, Wuttke, Joachim wrote:
Dear specialists,
I need more help. Specifically, I am going to ask 3 questions.
My debian directory is still messed up, as it has been from the beginning:
either the automatic scripts are not ready to assist in generating a
shared-library
package, or I used them in wrong way.
Here my control file :
---
Source: lmfit
Priority: extra
Maintainer: Joachim Wuttke j.wut...@fz-juelich.de
Build-Depends: debhelper (= 7), autotools-dev
Standards-Version: 3.8.4
Section: libs
Homepage: http://messen-und-deuten.de/lmfit/lmfit.html
Package: lmfit-dev
Section: libdevel
Architecture: any
Depends: lmfit (= ${binary:Version}), ${misc:Depends}
Description: Development files for Levenberg-Marquardt library lmfit
A self-contained implementation of the Levenberg-Marquardt algorithm.
Routine lmmin determines a parameter vector p that minimizes the Euclidean
norm of a vectorial function v(p). The most important application is curve
fitting: to approximate data y(t) by a function f(t;p), routine lmfit
minimizes the norm of the residual vector v = y(t) - f(t;p).
.
This package contains the include file lmmin.h and some application examples.
Package: lmfit3
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Least-squares minimization and curve fitting
A self-contained implementation of the Levenberg-Marquardt algorithm.
Routine lmmin determines a parameter vector p that minimizes the Euclidean
norm of a vectorial function v(p). The most important application is curve
fitting: to approximate data y(t) by a function f(t;p), routine lmfit
minimizes the norm of the residual vector v = y(t) - f(t;p).
.
This package contains the shared library and the man page lmfit(3).
---
Stanislav suggested I create an additional doc package. Given the small
size of the entire project, I tend to think it's better not to inflate the
packaging
overhead and to leave the examples in the dev package.
Technically speaking, the content of *-dev package is needed only for
compilation. Now imagine that your library became so popular that 1000
packages in debian build-depend on it. That means that when
autobuilding them your *-dev package will have to be unpacked,
installed and purged 1000 times for 1000 builds, with all its content.
Question 1:
Is that permissible, or absolutely forbidden by some rule ?
No, it is not forbidden by the policy, but it is simply not the best
thing to do, IMO.
Stanislav suggested the package name lmfit0.
No, I did not suggest _this_ name. Please reread my mail carefully.
By now, however, I succeeded in instructing autotools to generate the
correct shared library version number so.3.0.2; therefore, it's
lmfit3.
But I guess, the name of the file that gets installed into /usr/lib is
still liblmmin.so.X.Y.Z? Then, the name of the package with the
library should start with liblmmin.
Use this command ((C) Steve Langasek) to get the correct name
$ objdump -p liblmmin.so.3.0.2 | \
sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | \
sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//'
Another comment. There was nothing wrong with SONAME ending in 0,
because SONAME is not something that you change with every version.
(I hope you are not going to do that).
Now I need to hand-edit the install files.
Seems straightforward for lmfit3.install:
---
usr/lib/lib*.a
usr/lib/lib*.so
usr/lib/*.la
---
Less trivially, lmfit-dev.install should install the following:
lib/lmmin.h to prefix/include/lmmin.h
This file should not be a problem, as it is installed to
debian/tmp/usr/include/ by your Makefile at building time.
A line like
usr/include/*.h
should do the work. Read man dh_install.
doc/lmfit.3 to prefix/share/man/man3
This guy belongs to dh_installman. Read man dh_installman.
Add debian/*.manpages.
demo/* to ?
man dh_installexamples
Question 2:
Where should the demo sources be installed to ?
dh_installexamples installs them to /usr/share/doc/pkgname/examples
Question 3:
Is it possible to write an install file such that the source directory
(e.g. lib) is different from the destination directory (include) ?
Or do I need to first reorganize my source directories ?
You do not need to reorganize that, Debian tools are enough flexible.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Shared library packaging question
On Sat, Mar 27, 2010 at 06:57:03PM +0100, Wuttke, Joachim wrote: One more question (which possibly elucidates my previous questions): The upstream project is structured as follows: lmfit/configure.ac lmfit/Makefile.am # ... and all the resulting autotools stuff lmfit/lib/ # contains library sources and the include file lmmin.h lmfit/demo/ # contains application examples So, at present, by running the usual configure; make; make install sequence, one gets a working library installation plus working demo executables. Do I have to break that up before I can properly set up a shared-library package and a devdoc package ? No. You do not have to do that. -- Stanislav -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327185003.ga8...@kaiba.homelan
RE: Shared library packaging question
Thank you, Stanislav, for your helpful explanations. Regarding the name of the package: For many years the upstream project has been called lmfit (since the main application is curve fitting), but the shared library has been called lmmin.so (since the fundamental mathematical operation is minimization). This legacy makes it impossible to follow the most common mechanism (as the policy manual says) of choosing a package name that coincides with the library name. Hence the package name lmfit3. Version 3 as in upstream. Regarding the dev packages: Of course I will keep the development files separated from the shared library package. I just do not want thirdly a doc package; I still tend to pack the examples into the dev package. Kind regards, Joachim Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/eecf718003702b4f89104e3dbaa0ad030f93cd6...@mbx-cluster01.ad.fz-juelich.de
Re: Shared library packaging question
On Sat, Mar 27, 2010 at 08:24:05PM +0100, Wuttke, Joachim wrote: Thank you, Stanislav, for your helpful explanations. Regarding the name of the package: For many years the upstream project has been called lmfit (since the main application is curve fitting), but the shared library has been called lmmin.so (since the fundamental mathematical operation is minimization). This legacy makes it impossible to follow the most common mechanism (as the policy manual says) of choosing a package name that coincides with the library name. Hence the package name lmfit3. Just a couple of last comments: Many library packages in Debian have names very different from the names of their upstream's source packages. This is a common case when one source package generates several binary packages. Version 3 as in upstream. Well, just a few hours ago the upstream had 3 in the version and 0 in SONAME ;) On what I would like to stress is that in normal cases there is no simple equality between the soname and the version, and if there is, then ... it is a sign that there is a problem with the versioning scheme. Scrap it, and bash the upstream with the libtool manual. It is usually a good sign that either he has not read the manual thoroughly, or he has not understood it, or both. (Debian Library Packaging guide) Regarding the dev packages: Of course I will keep the development files separated from the shared library package. I just do not want thirdly a doc package; I still tend to pack the examples into the dev package. You seem to continously misread my mails. I was writing precisely about unpacking, installing and purging the *-dev package, and not the main library package (that will be always installed in parallel). -- Stanislav -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327201646.ga10...@kaiba.homelan
