Re: Library packaging and missing .a file

[Christian Kastner]

On 2014-04-25 07:58, Dariusz Dwornikowski wrote:
 On 24.04.14 10:23:23, Christian Kastner wrote:
 I have got another problem. Libstrophe only provides .a file, no .so,
 so basically it should provide only a -dev package. Is it ok to
 package only -dev, or is it agains policies?

Not that I'm aware of, but I very much question the usefulness of having
only a -dev package within the Debian archive.

If I were you, I'd simply patch upstream's build configuration to build
a shared library as well (and then forward the patch). Your upstream is
using autotools, so that should be trivial.

Christian


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535a076c.30...@kvr.at

Re: Library packaging and missing .a file

[Andrey Rahmatullin]

On Fri, Apr 25, 2014 at 08:57:48AM +0200, Christian Kastner wrote:
  I have got another problem. Libstrophe only provides .a file, no .so,
  so basically it should provide only a -dev package. Is it ok to
  package only -dev, or is it agains policies?
 
 Not that I'm aware of, but I very much question the usefulness of having
 only a -dev package within the Debian archive.
 
 If I were you, I'd simply patch upstream's build configuration to build
 a shared library as well (and then forward the patch). Your upstream is
 using autotools, so that should be trivial.
That requires maintaining ABI.

-- 
WBR, wRAR


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140425115948.ga28...@belkar.wrar.name

Re: Library packaging and missing .a file

[Rebecca N. Palmer]

 so basically it should provide only a -dev package. Is it ok to
 package only -dev, or is it agains policies?

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535a9dab.8070...@bham.ac.uk

Library packaging and missing .a file

[Dariusz Dwornikowski]

Hi,

I am packaging libstrophe XMPP library in order to introduce www.profanity.im 
to Debian.

make[2]: Entering directory `/home/tdi/dev/libstrophe-0.8.4'
 /bin/mkdir -p 
'/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/lib/x86_64-linux-gnu'
 /usr/bin/install -c -m 644  libstrophe.a 
'/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/lib/x86_64-linux-gnu'
 ( cd '/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/lib/x86_64-linux-gnu'  
ranlib libstrophe.a )
 /bin/mkdir -p '/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/include'
 /usr/bin/install -c -m 644 strophe.h 
'/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/include'
make[2]: Leaving directory `/home/tdi/dev/libstrophe-0.8.4'
make[1]: Leaving directory `/home/tdi/dev/libstrophe-0.8.4'
   dh_install
dh_install: libstrophe-dev missing files (usr/lib/lib*.a), aborting

The libstrophe.a file is installed into /usr/lib/x86_64-linux-gnu,
instead of /usr/lib. When should the .a file be installed into
/usr/lib and when into x86... ? 

My .install file looks like this, however dh_auto_install still
installs files into x86... because it runs before dh_install. Should I override 
dh_auto_install and 
depend only on d/install file ?

usr/include/*   

   
usr/lib/lib*.a
usr/lib/lib*.so
usr/lib/pkgconfig/*
usr/share/pkgconfig/*


-- 
Dariusz Dwornikowski, 
  Institute of Computing Science, Poznań University of Technology
  www.cs.put.poznan.pl/ddwornikowski/  
  room 2.7.2 BTiCW | tel. +48 61 665 29 41


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140424061634.ga28...@blackstar.cs.put.poznan.pl

Re: Library packaging and missing .a file

[Christian Kastner]

On 2014-04-24 08:16, Dariusz Dwornikowski wrote:
 dh_install: libstrophe-dev missing files (usr/lib/lib*.a), aborting
 
 The libstrophe.a file is installed into /usr/lib/x86_64-linux-gnu,
 instead of /usr/lib. When should the .a file be installed into
 /usr/lib and when into x86... ?

The new destinations are compliant with the multiarch specification[0].
You're probably using debhelper compat level 9, which automates much of
this.

 My .install file looks like this, however dh_auto_install still
 installs files into x86... because it runs before dh_install. Should I 
 override dh_auto_install and 
 depend only on d/install file ?
 
 usr/include/* 
   

 usr/lib/lib*.a
 usr/lib/lib*.so
 usr/lib/pkgconfig/*
 usr/share/pkgconfig/*

It is sufficient to change these to eg:

   usr/lib/*/lib*.a

but you should definitely read the implementation guide[1] to check for
other gotchas, etc.


[0] https://wiki.debian.org/Multiarch
[1] https://wiki.debian.org/Multiarch/Implementation


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5358c9f3.20...@kvr.at

Re: Library packaging and missing .a file

[Dariusz Dwornikowski]

On 24.04.14 10:23:23, Christian Kastner wrote:
 
 It is sufficient to change these to eg:
 
usr/lib/*/lib*.a

Thanks for this.

I have got another problem. Libstrophe only provides .a file, no .so,
so basically it should provide only a -dev package. Is it ok to
package only -dev, or is it agains policies?

-- 
Dariusz Dwornikowski, 
  Institute of Computing Science, Poznań University of Technology
  www.cs.put.poznan.pl/ddwornikowski/  
  room 2.7.2 BTiCW | tel. +48 61 665 29 41


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140425055829.gb28...@blackstar.cs.put.poznan.pl

Re: shared library packaging

[Adrian von Bidder]

Heyho!

On Thursday 05 August 2010 21.57:06 Michael Tautschnig wrote:
 Current dpkg (versions in testing and unstable) has a
 version of dpkg-gensymbols that supports symbol tags, including the c++
 tag.

Ah.  Yes, RTFM, but the dpkg-gensymbols manpage is refeerence documentation 
and not easy to read if I only have a very basic understanding of symbol 
stuff.  Once I realized that dpkg-gensymbols is called internally from 
dh_mkshlibs, I admit I stopped...

anyway, thanks a lot.  Simon, to you too, for your explanation.

cheers
-- vbi

-- 
Would ye both eat your cake and have your cake?
-- John Heywood


signature.asc
Description: This is a digitally signed message part.

shared library packaging

[Adrian von Bidder]

Heyho!

[cc:s welcome, thank you.]

I was recently made aware that my management of webkitkde / libkwerbkit1 
was quite a mess.  I've now tried to get the package in better shape 
(0.9.6svn1158036-2) by adding symbol files and renaming the library 
package back so the library package matches the soname and not the 
version name (I was confused because the library is installed as 
libkwebkit0.9.5 but has libkwebkit.so.1 as the soname.)

I'd be very happy for a few hints on how to manage the package.  I know 
I should watch for changes to the symbols, but I'm not quite sure how to 
manage the symbol files.  Looking at the buildd logs, I can see that 
there are quite a few ABIs (I guess C++ is guilty here.)

I usually build for i386, so I could of course just ignore the other 
arches, but I don't think that's what I'm supposed to do.  Hunting down 
the symbol files for all other architectures before uploading a new 
version is quite a hassle (or is there an easier way than getting 
accounts, so library maintainers really do this?

cheers
-- vbi

-- 
This bug is quite subtle and only happens in a very interesting
situation where a real-time threaded process is in the middle of a
coredump when someone whacks it with a SIGKILL.
-- Bhavesh P. Davda, describing a Linux kernel bug


signature.asc
Description: This is a digitally signed message part.

Re: shared library packaging

[Michael Tautschnig]

[...] (Adrian would like to be CC'ed)

 
 I'd be very happy for a few hints on how to manage the package.  I know 
 I should watch for changes to the symbols, but I'm not quite sure how to 
 manage the symbol files.  Looking at the buildd logs, I can see that 
 there are quite a few ABIs (I guess C++ is guilty here.)
 
 I usually build for i386, so I could of course just ignore the other 
 arches, but I don't think that's what I'm supposed to do.  Hunting down 
 the symbol files for all other architectures before uploading a new 
 version is quite a hassle (or is there an easier way than getting 
 accounts, so library maintainers really do this?
 

Not sure whether I'm missing some other questions in this post, but as far as
symbols are concerned: Current dpkg (versions in testing and unstable) has a
version of dpkg-gensymbols that supports symbol tags, including the c++ tag.
This allows the use of demangled symbols (no hazzle with arch-specific ABI),
which you can even combine with regular expressions (for arch-specific API, such
as long vs. int, etc.).

The man-page of dpkg-gensymbols has all the information; if you want to look at
an example, see the diagnostics package, I'm happily using these new features
over there.

Best,
Michael



pgprYg4lUP8BP.pgp
Description: PGP signature

Shared library packaging question

[Wuttke, Joachim]

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

[Wuttke, Joachim]

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

[Stanislav Maslovski]

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

[Stanislav Maslovski]

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

[Wuttke, Joachim]

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

[Stanislav Maslovski]

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

Need advices library packaging.

[Anthony Gasperin]

Hi everybody,
I'm intended to package axis2c api, which is a set of api for implement soap
service/client.
My problem is that I do not know how to process with library packaging,
I am wondering if somebody would know where I could find relative
documentation.

Thanks a lot !

Re: Need advices library packaging.

[Paul Wise]

On Tue, Mar 17, 2009 at 10:40 PM, Anthony Gasperin
anthony.gaspe...@gmail.com wrote:

 My problem is that I do not know how to process with library packaging,
 I am wondering if somebody would know where I could find relative
 documentation.

http://packages.debian.org/libpkg-guide
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

It has some bugs though (top two are most important):

http://bugs.debian.org/libpkg-guide

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Need advices library packaging.

[S'orlok Reaves]

Hello,
   Assuming that you have double-checked that you are reading to package 
axis2c, the new maintainer's guide is a very good place to begin:
http://www.debian.org/doc/maint-guide/

   If you prefer a guided example, I found this article helpful:
http://www.debian-administration.org/articles/336

   ...it's a little bit dated (2006), but that's what man pages are for. ;)

   Also, I found it helpful to download a small, existing package, and look at 
the debian/ directory that comes with it.

   If you get stuck, Google for the error you're receiving; someone's probably 
already had that same error.

Good luck,
--Seth




--- On Tue, 3/17/09, Anthony Gasperin anthony.gaspe...@gmail.com wrote:

 From: Anthony Gasperin anthony.gaspe...@gmail.com
 Subject: Need advices library packaging.
 To: debian-mentors@lists.debian.org
 Date: Tuesday, March 17, 2009, 9:40 AM
 Hi everybody,
 I'm intended to package axis2c api, which is a set of
 api for implement soap
 service/client.
 My problem is that I do not know how to process with
 library packaging,
 I am wondering if somebody would know where I could find
 relative
 documentation.
 
 Thanks a lot !


  


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Need advices library packaging.

[Anthony Gasperin]

Hello,
Thanks for answering,
I read debian maintainer's guide but packaging axis2c seems to be different
than package a simple ( or multiple )  binary file, axis2c is about library.
Moroever should I separate the axis2c soap server and the library ? meanning
create two
different package ...

Is there a guide process, like packaging binary file, for library packaging
?

2009/3/17 S'orlok Reaves sorlok_rea...@yahoo.com




 Hello,
   Assuming that you have double-checked that you are reading to package
 axis2c, the new maintainer's guide is a very good place to begin:
 http://www.debian.org/doc/maint-guide/

   If you prefer a guided example, I found this article helpful:
 http://www.debian-administration.org/articles/336

   ...it's a little bit dated (2006), but that's what man pages are for. ;)

   Also, I found it helpful to download a small, existing package, and look
 at the debian/ directory that comes with it.

   If you get stuck, Google for the error you're receiving; someone's
 probably already had that same error.

 Good luck,
 --Seth




 --- On Tue, 3/17/09, Anthony Gasperin anthony.gaspe...@gmail.com wrote:

  From: Anthony Gasperin anthony.gaspe...@gmail.com
  Subject: Need advices library packaging.
  To: debian-mentors@lists.debian.org
  Date: Tuesday, March 17, 2009, 9:40 AM
  Hi everybody,
  I'm intended to package axis2c api, which is a set of
  api for implement soap
  service/client.
  My problem is that I do not know how to process with
  library packaging,
  I am wondering if somebody would know where I could find
  relative
  documentation.
 
  Thanks a lot !





 --
 To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org

Re: advise needed for library packaging

[Bernhard R. Link]

* Paul Wise p...@debian.org [081229 01:01]:
 I would suggest adding a .symbols file for the new ABI so you can
 detect ABI breakage in newer upstream versions.

s/so you can detect/so dpkg-gensymbols can warn in case of some easy to detect /

Before someone thinks that a symbols file suffices to check for ABI
breakage
After all it can only check the most notorious ones, manual work is
still needed to be sure...

Hochachtungsvoll,
Bernhard R. Link
-- 
Never contain programs so few bugs, as when no debugging tools are available!
Niklaus Wirth


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: advise needed for library packaging

[George Danchev]

On Tuesday 30 December 2008 04:04:55 Paul Wise wrote:
 On Tue, Dec 30, 2008 at 5:12 AM, George Danchev danc...@spnet.net wrote:
  Why is libfoo-X-dev better than libfooX-dev, where 'X' is being some sort
  of API version discriminator ?

 Both of those are the same, 

I'm glad to read that.

 my comment was about libfooABI-API-dev vs libfoo-API-dev.

Yes, your wording made that clear, the latter is preferred.

To summarize: 
* if the ABI has changed, but the API remains the same, then change the 
library package name, but not the -dev package one. 
* if the API has changed, both -dev and library package names should be 
changed.

I wonder if such a wording would address the valid complain of #493951 ?

-- 
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: advise needed for library packaging

[George Danchev]

On Tuesday 30 December 2008 00:07:34 Neil Williams wrote:
 On Mon, 29 Dec 2008 22:12:24 +0200

 George Danchev danc...@spnet.net wrote:
   http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
   http://bugs.debian.org/libpkg-guide
  
   Firstly, do you need that library? Nothing in sid seems to depend on
   it, not even sleuthkit.
 
  Library packages which nobody {build-}depends on yet, sits in the same
  boat as the rest of the leaf (application) packages, so general rules
  should apply:

 I think that is an error. Libraries are intrinsically harder to package
 correctly and have more implications for the archive than applications.
 e.g. applications don't change binary package name (let alone source
 package name) on a routine basis. A library package without reverse
 dependencies is less useful than a leaf application with more intrinsic
 problems and more hassle, therefore counts as less desirable than a
 leaf application.

Libraries being intrinsically harder to package correctly does not make those 
of them with no reverse build dependencies being useless to the users who 
would like use them and prefer them in the form of debian packages (just like 
any other leaf packages). Currently Debian main contains 1489 -dev packages 
with no reverse build-depends found for them. Do you really believe that 
these are some sort of massive fallacy (assuming ~10% of them being false 
positives and not relevant to the topic like manpages-dev) and waste of 
packaging time. 

   -dev packages should not have SONAMEs in their package names,

 ? -dev packages can have SONAMEs in the package name - but in most
 situations, the extra complexity isn't worth it.

   what is
   the reason for the libtsk-dev - libtsk3-3-dev change? If the API has
   changed incompatibly, libtsk-3-dev might be more appropriate.
 
  Why is libfoo-X-dev better than libfooX-dev, where 'X' is being some sort
  of API version discriminator ?

 IMHO libtsk-dev should only change to libtsk3-dev - I don't see the
 need for libtsk-3-dev (I suspect you'll get a lintian warning).
 libtsk3-3-dev is only if the upstream API is so unstable that you will
 need a libtsk3-4-dev instead of migrating smoothly to libtsk4.
 Personally, I'd look at the glib and gtk model of libfooN.N rather than
 libfooN-N if there is a good reason to not use libfoo-dev or
 libfooN-dev.

 some sort of API version discriminator doesn't sound as if you've
 understood SONAME transitions.

... or you better understand [1] that you should avoid keeping SONAME 
artifacts in the -dev package names, thus avoid changing -dev package name on 
each SONAME bump, which would make release team cry upon transitions, loudly.

[1] these comments from Stephen Frost would help ;-)
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#ftn.id292176

-- 
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: advise needed for library packaging

[Neil Williams]

On Tue, 30 Dec 2008 16:30:28 +0200
George Danchev danc...@spnet.net wrote:

  some sort of API version discriminator doesn't sound as if you've
  understood SONAME transitions.
 
 ... or you better understand [1] that you should avoid keeping SONAME 
 artifacts in the -dev package names, thus avoid changing -dev package name on 
 each SONAME bump, which would make release team cry upon transitions, loudly.
 
Which is why, generally, I prefer to use libfoo-dev - it isn't an
argument (to me) for using some number other than the SONAME in the
-dev package name. It would be particularly confusing to use a number
in the -dev package name that is just some sort of API discriminator
but that had no relation to the actual SONAME. If a number is used, it
should change in step with the transitions and be predictable from
objdump -p.

However, once a transition does come along, if you want to retain
libfoo1.2-dev and libfoo2.0-dev, then it makes more work for some but
allows libraries with hundreds and hundreds of reverse-dependencies to
have a sensible migration path. Such libraries are few and far between,
thankfully, but the ability to retain the SONAME in the -dev package
name (and the source package name) is important for a small number of
fundamental libraries. There is then the inevitable pain of deciding
that libfoo1.2 simply has to go away at some point. :-)

Where would we be without libc6-dev ?

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpHEMY117W1l.pgp
Description: PGP signature

Re: advise needed for library packaging

[George Danchev]

On Monday 29 December 2008 02:01:56 Paul Wise wrote:
 On Sun, Dec 28, 2008 at 6:04 PM, Martin Godisch mar...@godisch.de wrote:
  I'm not doing library packaging all day and I'm a bit unsure about the
  new sleuthkit upstream release. It would be nice if some of you could
  have a look at sleuthkit 3.0.0 here [1] and 2.0.5 in unstable and tell
  me what I did wrong with the new release regarding upgrade path and
  soname change and such.

 Firstly, make sure you've read libpkg-guide and it's bugs (especially
 the RC one):

 http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
 http://bugs.debian.org/libpkg-guide

 Firstly, do you need that library? Nothing in sid seems to depend on
 it, not even sleuthkit.

Library packages which nobody {build-}depends on yet, sits in the same boat as 
the rest of the leaf (application) packages, so general rules should apply: 
if the library is really useful (i.e. generic) for the mere programmers, who 
are Debian users in that case and helps them to reduce redundancy (not 
reinventing the wheel every now and then, and not wasting disk space all over 
the place) has its place in the Debian archive, of course provided there is 
someone to take care of it. Does that make sense?

 I would suggest adding a .symbols file for the new ABI so you can
 detect ABI breakage in newer upstream versions.

 -dev packages should not have SONAMEs in their package names, what is
 the reason for the libtsk-dev - libtsk3-3-dev change? If the API has
 changed incompatibly, libtsk-3-dev might be more appropriate.

Why is libfoo-X-dev better than libfooX-dev, where 'X' is being some sort of 
API version discriminator ?

-- 
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: advise needed for library packaging

[Neil Williams]

On Mon, 29 Dec 2008 22:12:24 +0200
George Danchev danc...@spnet.net wrote:

  http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
  http://bugs.debian.org/libpkg-guide
 
  Firstly, do you need that library? Nothing in sid seems to depend on
  it, not even sleuthkit.
 
 Library packages which nobody {build-}depends on yet, sits in the same boat 
 as 
 the rest of the leaf (application) packages, so general rules should apply: 

I think that is an error. Libraries are intrinsically harder to package
correctly and have more implications for the archive than applications.
e.g. applications don't change binary package name (let alone source
package name) on a routine basis. A library package without reverse
dependencies is less useful than a leaf application with more intrinsic
problems and more hassle, therefore counts as less desirable than a
leaf application.

 if the library is really useful (i.e. generic) for the mere programmers, who 
 are Debian users in that case and helps them to reduce redundancy (not 
 reinventing the wheel every now and then, and not wasting disk space all over 
 the place) has its place in the Debian archive, of course provided there is 
 someone to take care of it. Does that make sense?

Sometimes - but note, only *sometimes*. There are very few truly
generic libraries because most of the low level stuff is dealt with in
robust, team maintained and thoroughly debugged libraries like glib2.0.
I find it hard to see where there are any appreciable niches where a
generic library is actually missing - at least when considering
libraries written in C (I don't use C++ much).

Now, perl libraries and other interpreted languages - there is lots and
lots of space for generic, low level libraries but not so much in C.

I did package one library without reverse dependencies (soci) and I had
cause to regret it very recently - thankfully Bradley Smith found a
need to use it and has taken over maintenance.

  I would suggest adding a .symbols file for the new ABI so you can
  detect ABI breakage in newer upstream versions.

Definitely.

  -dev packages should not have SONAMEs in their package names, 

? -dev packages can have SONAMEs in the package name - but in most
situations, the extra complexity isn't worth it.

  what is
  the reason for the libtsk-dev - libtsk3-3-dev change? If the API has
  changed incompatibly, libtsk-3-dev might be more appropriate.
 
 Why is libfoo-X-dev better than libfooX-dev, where 'X' is being some sort of 
 API version discriminator ?

IMHO libtsk-dev should only change to libtsk3-dev - I don't see the
need for libtsk-3-dev (I suspect you'll get a lintian warning).
libtsk3-3-dev is only if the upstream API is so unstable that you will
need a libtsk3-4-dev instead of migrating smoothly to libtsk4.
Personally, I'd look at the glib and gtk model of libfooN.N rather than
libfooN-N if there is a good reason to not use libfoo-dev or
libfooN-dev.

some sort of API version discriminator doesn't sound as if you've
understood SONAME transitions.

libtsk-dev vs libtsk3-dev is a question of stability and transition -
whether you want to retain the old version when migrating to the next,
ala gtk1.2 to gtk2.0 but most libraries don't need this. Libraries that
do not have reverse dependencies certainly do not need this. ;-)

Generally, I prefer to use an unversioned library source package name
(qof) and an unversioned -dev binary package name (libqof-dev). It
doesn't makes much sense to have a versioned -dev without a versioned
source package name because you will still lose the old libfooN-dev
when the new version of foo is uploaded. Retaining the old and new
source packages is only worthwhile if migration from old to new is
going to take a significant amount of effort on the part of a
significant number of reverse dependencies.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpQSpGoPsCyd.pgp
Description: PGP signature

Re: advise needed for library packaging

[Paul Wise]

On Tue, Dec 30, 2008 at 5:12 AM, George Danchev danc...@spnet.net wrote:

 Why is libfoo-X-dev better than libfooX-dev, where 'X' is being some sort of
 API version discriminator ?

Both of those are the same, my comment was about libfooABI-API-dev vs
libfoo-API-dev.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: advise needed for library packaging

[Paul Wise]

On Sun, Dec 28, 2008 at 6:04 PM, Martin Godisch mar...@godisch.de wrote:

 I'm not doing library packaging all day and I'm a bit unsure about the
 new sleuthkit upstream release. It would be nice if some of you could
 have a look at sleuthkit 3.0.0 here [1] and 2.0.5 in unstable and tell
 me what I did wrong with the new release regarding upgrade path and
 soname change and such.

Firstly, make sure you've read libpkg-guide and it's bugs (especially
the RC one):

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
http://bugs.debian.org/libpkg-guide

Firstly, do you need that library? Nothing in sid seems to depend on
it, not even sleuthkit.

I would suggest adding a .symbols file for the new ABI so you can
detect ABI breakage in newer upstream versions.

-dev packages should not have SONAMEs in their package names, what is
the reason for the libtsk-dev - libtsk3-3-dev change? If the API has
changed incompatibly, libtsk-3-dev might be more appropriate.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Library Packaging

[Jonathan Steel]

Hi

I'm trying to create a package of a shared library and I can't figure 
out how to do it. I can do it for a normal binary using dh_make and 
debuild. Ive read through all the debian packaging guides I can find. 
But there is a lack of info on how to do it for shared libraries. I end 
up with a .deb that doesn't install anything except for the changelog.


Where can I look for help?

Thanks


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library Packaging

[David Paleino]

On Fri, 03 Oct 2008 16:16:47 -0400, Jonathan Steel wrote:

 Hi
 
 I'm trying to create a package of a shared library and I can't figure 
 out how to do it. I can do it for a normal binary using dh_make and 
 debuild.

You already tried with dh_make -l, right?

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Library Packaging

[Neil Williams]

On Fri, 2008-10-03 at 16:16 -0400, Jonathan Steel wrote:
 Hi
 
 I'm trying to create a package of a shared library and I can't figure 
 out how to do it. I can do it for a normal binary using dh_make and 
 debuild. Ive read through all the debian packaging guides I can find. 

Shared libraries are difficult packages to maintain - do you understand
the issues around SONAMEs, transitions, -dbg packages and how to work
with upstream on symbol versioning etc.?

Generally, I don't recommend that anyone on this list seriously
considers packaging shared libraries until they have a couple of
ordinary binary packages in the archive. 

 But there is a lack of info on how to do it for shared libraries. I end 
 up with a .deb that doesn't install anything except for the changelog.
 
 Where can I look for help?

/me thinks I'm going to have to write a little guide on this but lack
the time right now.

First point of call is debian/dirs - make sure it's not referencing
things like usr/sbin usr/bin - you probably don't need that file at all.

Now create the libfoo0.install, libfoo-dev.install (or
libfoo0-dev.install depending on how you want to manage and maintain the
transitions) files to contain the relevant objects.

Take a look at the .install files for a few shared libraries -
naturally, I'd recommend QOF (libqof1 in Debian until Lenny is released
when libqof2 will arrive). Ignore the stuff in debian/rules, concentrate
on the .install files and control file.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: Library Packaging

[Craig Small]

On Fri, Oct 03, 2008 at 09:44:44PM +0100, Neil Williams wrote:
 Generally, I don't recommend that anyone on this list seriously
 considers packaging shared libraries until they have a couple of
 ordinary binary packages in the archive. 
I would agree with that.  Debian packaging is quite daunting for someone
who's not seen it before, let alone packaging a library. Some upstream
Makefiles are packager-friendly and others it looks like they go out of
their way to make life tough.

dh-make helps, but it cannot cater for everything.  Another problem with
your email is you don't actually say what is going wrong.

 - Craig
-- 
Craig Small  GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/ csmall at : enc.com.au
http://www.debian.org/  Debian GNU/Linux, software should be Free 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library Packaging

[Kapil Hari Paranjape]

Hello,

On Fri, 03 Oct 2008, Neil Williams wrote:
 On Fri, 2008-10-03 at 16:16 -0400, Jonathan Steel wrote:
  I'm trying to create a package of a shared library and I can't figure 
  out how to do it. I can do it for a normal binary using dh_make and 
  debuild. Ive read through all the debian packaging guides I can find. 

 Generally, I don't recommend that anyone on this list seriously
 considers packaging shared libraries until they have a couple of
 ordinary binary packages in the archive. 

/me agrees.

 /me thinks I'm going to have to write a little guide on this but lack
 the time right now.

There is a guide covering some of the basic issues at
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

Kapil.
--



signature.asc
Description: Digital signature

Re: Library Packaging

[Paul Wise]

On Sat, Oct 4, 2008 at 8:50 AM, Kapil Hari Paranjape [EMAIL PROTECTED] wrote:

 There is a guide covering some of the basic issues at
 http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

Unfortunately it doesn't yet cover using symbols files, for more info
on that see these:

http://wiki.debian.org/UsingSymbolsFiles
http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
http://manpages.debian.net/cgi-bin/man.cgi?query=dpkg-shlibdeps
http://manpages.debian.net/cgi-bin/man.cgi?query=deb-symbols
http://manpages.debian.net/cgi-bin/man.cgi?query=dpkg-gensymbols

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

RE: library packaging problem

[mzenker]

The source can be found at 
http://prdownloads.sourceforge.net/ulxmlrpcpp/ulxmlrpcpp-1.4.5.tar.bz2.

But I have some doubts that my problem is related to the upstream source.

The strange thing is that the debian/rules file invokes dh_builddeb, but when I call 
it manually immediately after the package build process, I get

dpkg-deb: failed to open package info file 'debian/tmp/DEBIAN/control' for reading: No 
such file or directory

I dont't get this error during the package build process.

BTW, all this happens on a woody system.

Thank you for any hint,

Matthias


GN Otometrics -- Hortmann   
Dipl.Phys. Dr. Matthias Zenker
Entwicklung / Development
Auchtertstraße 4, D-72770 Reutlingen
Tel. ++49(0)7121/99435-60, Fax -79
eMail: [EMAIL PROTECTED]
http://www.hortmann.de  



 -Original Message-
 From: Laszlo 'GCS' Boszormenyi [mailto:[EMAIL PROTECTED] 
 Sent: Monday, August 23, 2004 8:41 PM
 To: Zenker, Matthias (Otometrics Stuttgart)
 Cc: [EMAIL PROTECTED]
 Subject: Re: library packaging problem
 
 
 * [EMAIL PROTECTED] [EMAIL PROTECTED] 
 [2004-08-23 18:16:20 +0200]:
 
  Could anyone give me a hint where I have to look to find my 
 (certainly 
  trivial) error?
  Can we look into the package's source? Without checking we 
 have a hard time guessing.
 
 Regards,
 Laszlo/GCS
 
 

RE: library packaging problem

[mzenker]

Hi,

I have solved my problem of empty .debs in a library package: in the debian/rules 
file, I had to change the install command from

$(MAKE) install prefix=$(CURDIR)/debian/tmp

to read

$(MAKE) install prefix=$(CURDIR)/debian/tmp/usr

so that dh_movefiles could move the files into debian/packagename/usr/ since they 
should be installed in /usr/ at the end, as was correctly indicated in the 
debian/packagename.files files.

Since debian/rules and debian/packagename.files were both created by 
dpkg-buildpackage (and I did not change them in the first place), one should expect 
that such manual fixing is not needed - could this be a bug?

Best regards,

Matthias


GN Otometrics -- Hortmann   
Dipl.Phys. Dr. Matthias Zenker
Entwicklung / Development
Auchtertstraße 4, D-72770 Reutlingen
Tel. ++49(0)7121/99435-60, Fax -79
eMail: [EMAIL PROTECTED]
http://www.hortmann.de  

RE: library packaging problem

[mzenker]

The source can be found at 
http://prdownloads.sourceforge.net/ulxmlrpcpp/ulxmlrpcpp-1.4.5.tar.bz2.

But I have some doubts that my problem is related to the upstream source.

The strange thing is that the debian/rules file invokes dh_builddeb, but when I 
call it manually immediately after the package build process, I get

dpkg-deb: failed to open package info file 'debian/tmp/DEBIAN/control' for 
reading: No such file or directory

I dont't get this error during the package build process.

BTW, all this happens on a woody system.

Thank you for any hint,

Matthias


GN Otometrics -- Hortmann   
Dipl.Phys. Dr. Matthias Zenker
Entwicklung / Development
Auchtertstraße 4, D-72770 Reutlingen
Tel. ++49(0)7121/99435-60, Fax -79
eMail: [EMAIL PROTECTED]
http://www.hortmann.de  



 -Original Message-
 From: Laszlo 'GCS' Boszormenyi [mailto:[EMAIL PROTECTED] 
 Sent: Monday, August 23, 2004 8:41 PM
 To: Zenker, Matthias (Otometrics Stuttgart)
 Cc: debian-mentors@lists.debian.org
 Subject: Re: library packaging problem
 
 
 * [EMAIL PROTECTED] [EMAIL PROTECTED] 
 [2004-08-23 18:16:20 +0200]:
 
  Could anyone give me a hint where I have to look to find my 
 (certainly 
  trivial) error?
  Can we look into the package's source? Without checking we 
 have a hard time guessing.
 
 Regards,
 Laszlo/GCS
 
 

RE: library packaging problem

[mzenker]

Below is the output of dpkg-buildpackage -rfakeroot. Perhaps anyone can see 
what went wrong?

Thank you,

Matthias

---OUTPUT BEGIN

dpkg-buildpackage: source package is libulxmlrpcpp
dpkg-buildpackage: source version is 1.4.5-1
dpkg-buildpackage: source maintainer is Matthias Zenker [EMAIL PROTECTED]
dpkg-buildpackage: host architecture is i386
 fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp 
# Add here commands to clean up after the build process.
/usr/bin/make distclean
make[1]: Entering directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5'
Making distclean in stubber
make[2]: Entering directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/stubber'
 rm -f ulxrstubber ulxrstubber
test -z *.~* *.~~* *~ || rm -f *.~* *.~~* *~
rm -rf .libs _libs
rm -f *.o core *.core
rm -f *.lo
rm -f *.tab.c
rm -rf ./.deps
rm -f Makefile 
rm -f libtool
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
make[2]: Leaving directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/stubber'
Making distclean in contrib
make[2]: Entering directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/contrib'
Making distclean in java-demo
make[3]: Entering directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/contrib/java-demo'
 rm -f sum_server sum_server
test -z *.~* *.~~* *~ || rm -f *.~* *.~~* *~
rm -rf .libs _libs
rm -f *.o core *.core
rm -f *.lo
rm -f *.tab.c
rm -rf ./.deps
rm -f Makefile 
rm -f libtool
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
make[3]: Leaving directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/contrib/java-demo'
Making distclean in .
make[3]: Entering directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/contrib'
test -z *.~* *.~~* *~ || rm -f *.~* *.~~* *~
rm -rf .libs _libs
rm -f *.lo
rm -f Makefile 
rm -f libtool
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
make[3]: Leaving directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/contrib'
make[2]: Leaving directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/contrib'
Making distclean in expat
make[2]: Entering directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/expat'
rm -rf .libs _libs
rm -f *.lo
rm -f Makefile 
rm -f libtool
make[2]: Leaving directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/expat'
Making distclean in msvc
make[2]: Entering directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/msvc'
Making distclean in ulxmlrpcpp
make[3]: Entering directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/msvc/ulxmlrpcpp'
rm -rf .libs _libs
rm -f *.lo
rm -f Makefile 
rm -f libtool
make[3]: Leaving directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/msvc/ulxmlrpcpp'
Making distclean in .
make[3]: Entering directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/msvc'
test -z *.~* *.~~* *~ || rm -f *.~* *.~~* *~
rm -rf .libs _libs
rm -f *.lo
rm -f Makefile 
rm -f libtool
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
make[3]: Leaving directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/msvc'
make[2]: Leaving directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/msvc'
Making distclean in bcb5
make[2]: Entering directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/bcb5'
Making distclean in libexpat
make[3]: Entering directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/bcb5/libexpat'
test -z *.~* *.~~* *~ || rm -f *.~* *.~~* *~
rm -rf .libs _libs
rm -f *.lo
rm -f Makefile 
rm -f libtool
make[3]: Leaving directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/bcb5/libexpat'
Making distclean in .
make[3]: Entering directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/bcb5'
test -z *.~* *.~~* *~ || rm -f *.~* *.~~* *~
rm -rf .libs _libs
rm -f *.lo
rm -f Makefile 
rm -f libtool
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
make[3]: Leaving directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/bcb5'
make[2]: Leaving directory `/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/bcb5'
Making distclean in ulxmlrpcpp
make[2]: Entering directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/ulxmlrpcpp'
Making distclean in apps
make[3]: Entering directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/ulxmlrpcpp/apps'
 rm -f meerkat_client meerkat_client
 rm -f introspect introspect
test -z *.~* *.~~* *~ || rm -f *.~* *.~~* *~
rm -rf .libs _libs
rm -f *.o core *.core
rm -f *.lo
rm -f *.tab.c
rm -rf ./.deps
rm -f Makefile 
rm -f libtool
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
make[3]: Leaving directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/ulxmlrpcpp/apps'
Making distclean in po
make[3]: Entering directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/ulxmlrpcpp/po'
test -z *.~* *.~~* *~ || rm -f *.~* *.~~* *~
rm -rf .libs _libs
rm -f *.lo
rm -f Makefile 
rm -f libtool
make[3]: Leaving directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/ulxmlrpcpp/po'
Making distclean in httpd
make[3]: Entering directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/ulxmlrpcpp/httpd'
rm -rf .libs _libs
rm -f *.lo
rm -f Makefile 
rm -f libtool
make[3]: Leaving directory 
`/usr/local/ulxmlrpcpp/libulxmlrpcpp-1.4.5/ulxmlrpcpp/httpd'
Making distclean in tests
make[3]: Entering directory 

RE: library packaging problem

[mzenker]

Hi,

I have solved my problem of empty .debs in a library package: in the 
debian/rules file, I had to change the install command from

$(MAKE) install prefix=$(CURDIR)/debian/tmp

to read

$(MAKE) install prefix=$(CURDIR)/debian/tmp/usr

so that dh_movefiles could move the files into debian/packagename/usr/ since 
they should be installed in /usr/ at the end, as was correctly indicated in the 
debian/packagename.files files.

Since debian/rules and debian/packagename.files were both created by 
dpkg-buildpackage (and I did not change them in the first place), one should 
expect that such manual fixing is not needed - could this be a bug?

Best regards,

Matthias


GN Otometrics -- Hortmann   
Dipl.Phys. Dr. Matthias Zenker
Entwicklung / Development
Auchtertstraße 4, D-72770 Reutlingen
Tel. ++49(0)7121/99435-60, Fax -79
eMail: [EMAIL PROTECTED]
http://www.hortmann.de  

library packaging problem

[mzenker]

Hi,

I am trying to package a library. This is my first package (yes, I know that it is 
depreciated for packaging newbies, but I need it in my job...). I have used upstream 
.tar.gz sources (they use autoconf and automake) and tried to follow the new 
maintainer's guide. 
The problem is that the dpkg-buildpackage produces packages with just the docs, but no 
library files inside (the appropriate directories have been created, but they are 
empty), although they reside in debian/tmp. This is true for both the libxxx.deb and 
the libxxx-dev.deb

Could anyone give me a hint where I have to look to find my (certainly trivial) error?

Thank you,

Matthias


GN Otometrics -- Hortmann   
Dipl.Phys. Dr. Matthias Zenker
Entwicklung / Development
Auchtertstraße 4, D-72770 Reutlingen
Tel. ++49(0)7121/99435-60, Fax -79
eMail: mzenker at gnotometrics dot de
http://www.hortmann.de  

Re: library packaging problem

[Laszlo 'GCS' Boszormenyi]

* [EMAIL PROTECTED] [EMAIL PROTECTED] [2004-08-23 18:16:20 +0200]:

 Could anyone give me a hint where I have to look to find my (certainly trivial) 
 error?
 Can we look into the package's source? Without checking we have a hard
time guessing.

Regards,
Laszlo/GCS


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

library packaging problem

[mzenker]

Hi,

I am trying to package a library. This is my first package (yes, I know that it 
is depreciated for packaging newbies, but I need it in my job...). I have used 
upstream .tar.gz sources (they use autoconf and automake) and tried to follow 
the new maintainer's guide. 
The problem is that the dpkg-buildpackage produces packages with just the docs, 
but no library files inside (the appropriate directories have been created, but 
they are empty), although they reside in debian/tmp. This is true for both the 
libxxx.deb and the libxxx-dev.deb

Could anyone give me a hint where I have to look to find my (certainly trivial) 
error?

Thank you,

Matthias


GN Otometrics -- Hortmann   
Dipl.Phys. Dr. Matthias Zenker
Entwicklung / Development
Auchtertstraße 4, D-72770 Reutlingen
Tel. ++49(0)7121/99435-60, Fax -79
eMail: mzenker at gnotometrics dot de
http://www.hortmann.de  

Re: library packaging problem

[Laszlo 'GCS' Boszormenyi]

* [EMAIL PROTECTED] [EMAIL PROTECTED] [2004-08-23 18:16:20 +0200]:

 Could anyone give me a hint where I have to look to find my (certainly 
 trivial) error?
 Can we look into the package's source? Without checking we have a hard
time guessing.

Regards,
Laszlo/GCS

Re: updated library packaging FAQ

[David Schmitt]

Hi Junichi, Hi all!

After a first reading here are some commentss and some polishing.
Perhaps this should also be aired on debian-doc for further checking of
the language (I'm not perfect either..)

On Mon, Mar 18, 2002 at 01:07:36AM +0900, Junichi Uekawa wrote:
 [Traits of Debian]
 
 First, let us check what Debian is in the perspective of 
 maintaining library packages, and why Debian is different to 
 other systems.
 
 Debian is a binary-distribution-centric system.
 Binary is created from source, and they are the ones that 
The binaries are created from source packages and are the ones that
 gets distributed mainly.
get distributed.
 Binary is compiled from the source at time as a snapshot for one architecture,
The binaries are from the source as a snapshot for one architecture
 and several copies of binary is built from the same source at different points
and several copies of the binaries are built from the same source at
different times
 for different architectures, against different versions of the library
for different architectures, sometimes even against different versions
of libraries 
 that may exist at that point.
which have changed.

 Thus, unless one is careful, one has no control over which version of 
 specific development package a binary will be compiled with.

The SONAME of a library will help, as we will see in a moment.

:From the point of the distribution all packages should
use the same version to reduce the number of installed packages and
increase the possibility of sharing loaded libraries.


 Debian has a packaging scheme for libraries, with having
 libfooX package for run-time required library files,
 and libfooX-dev package for buid-time required library files.

[Missing contrast to other systems as promised in first sentence]

 [Recommended reading before doing library packages]
 
 It is recommended to read the info page for libtool,
 which is contained in the libtool-doc package.
 It explains many things in detail, and it talks about
... and talks about ...
 generic aspects of library programs not specific to Debian.

 Also, please read the Debian Policy carefully,
 and New Maintainer's Guide, and Developers Reference.

... read the respective documentation for packagers. Namely the Debian
Policy the New Maintainer's Guide and the Developers Reference.

[Perhaps collect some crossreferences to the relevant sections about
libraries]

 An experience of having your package broken by some 
 random library upgrade might be a plus.
 
 [Naming library packages]
 
 The policy documents how to name library packages.
   libpackagesoname
 like 
   libc6 for /lib/libc.so.6
 
 However, there are packages which contain libraries that look like this:
 
   /usr/lib/libsomepackage-1.2.so.0
 
 This is a library with a name of libsomepackage-1.2, and a soname of 0.
 The current practice in packaging such package seems to be to have 
   libsomepackage-1.2-0
 as the package name.
 
 It is taking the form of libpackage-soname format
To distinguish the package name and the soname, all library packages with
 to distinguish the package name and the soname, using the -.
a name ending in a numeric, the form libpackage-soname is
 This applies to all library packages which the name ends in a
preferred.
 numeric.

BTW: should't this be libraryname instead of packagename?

 [-DEV package names]
 
 It is ideal to have the soname in the package name, like the following:
 
 Package: libpackage2-dev
 Provides: libpackage-dev
 Conflicts: libpackage-dev
 
 This ensures that only one version of libpackageX-dev
 is installed, and also allows the maintainer of each package
 to selectively link with the expected library with the 
 expected soname version.
 
 It is possible to create 
 Package: libpackage-dev
 and it is allowed by policy. However, this allows
 any version of library libpackage to be linked.
 This has caused much problems, in libpng, and other
 packages. libpackage-dev notation should not be used 
 if it is going to be linked in by other library packages.

Even though the policy allows omitting the soname from the packagename
it is not encouraged, since this has caused much problems as in
libpng-dev and others, which could not live up to the promise of
neverchanging interfaces.

 
 [-DEV package dependencies]
 
 -dev package should depend on all -dev packages that the library
The -dev package should depend on all -dev packages for libraries that the library
 package depends upon, with the version that the library package is compiled
package depends upon, with the specific (so)version that the library package is
 against.
compiled against.


 e.g. 
 
 libFOO2-dev - libBAR2-dev
 because libFOO2 depends on libBAR2



 If you want libFOO2-dev that can compile with libBAR3-dev,
 the soname or something else should be fixed. The possible situation
 will be:
 libFOO3-dev - libBAR3-dev
   (discuss with upstream to coordinate the soname change)
 or
 libFOO2-libBAR3-dev - libBAR3-dev
 
 and have libFOO2 

Re: Library packaging

[Jamie Wilkinson]

This one time, at band camp, Junichi Uekawa wrote:
There could, however, be changes in the source
which does affect.

This is true, I feel there are many cases that are not easily tested; so I
will _not_ be trying to make a universal soname checker, guaranteed to work
100%.

I don't know if there could be a systematic way to do it.
Warning might be possible, but not strict and real checking.

Well, for header files I'm thinking of using a parser, then it would be easy
to compare syntax trees of the two versions.

Lintian won't be able to do this, because lintian only has access
to one version of source at the time.

Yes, I'm thinking of a separate program that library maintainers can use.

-- 
[EMAIL PROTECTED]   http://spacepants.org/jaq.gpg
 
liedra yay, there's wmaker for irix
liedra my life is complete ;)
Balial wmaker is pants!
liedra where pants stands for pretty amazingly neat t-something system
-- #sodfest97


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[Jamie Wilkinson]

This one time, at band camp, Mark Brown wrote:
That's a first step but it is also possible for there to be incompatible
semantic changes which can't be detected in this fashion.

This is true, but I'm not aiming to make the perfect tool -- I have strong
instincts that the complete problem intractable.

-- 
[EMAIL PROTECTED]   http://spacepants.org/jaq.gpg
 
A user and his leisure time are soon parted.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: updated library packaging FAQ

[David Schmitt]

Hi Junichi, Hi all!

After a first reading here are some commentss and some polishing.
Perhaps this should also be aired on debian-doc for further checking of
the language (I'm not perfect either..)

On Mon, Mar 18, 2002 at 01:07:36AM +0900, Junichi Uekawa wrote:
 [Traits of Debian]
 
 First, let us check what Debian is in the perspective of 
 maintaining library packages, and why Debian is different to 
 other systems.
 
 Debian is a binary-distribution-centric system.
 Binary is created from source, and they are the ones that 
The binaries are created from source packages and are the ones that
 gets distributed mainly.
get distributed.
 Binary is compiled from the source at time as a snapshot for one architecture,
The binaries are from the source as a snapshot for one architecture
 and several copies of binary is built from the same source at different points
and several copies of the binaries are built from the same source at
different times
 for different architectures, against different versions of the library
for different architectures, sometimes even against different versions
of libraries 
 that may exist at that point.
which have changed.

 Thus, unless one is careful, one has no control over which version of 
 specific development package a binary will be compiled with.

The SONAME of a library will help, as we will see in a moment.

:From the point of the distribution all packages should
use the same version to reduce the number of installed packages and
increase the possibility of sharing loaded libraries.


 Debian has a packaging scheme for libraries, with having
 libfooX package for run-time required library files,
 and libfooX-dev package for buid-time required library files.

[Missing contrast to other systems as promised in first sentence]

 [Recommended reading before doing library packages]
 
 It is recommended to read the info page for libtool,
 which is contained in the libtool-doc package.
 It explains many things in detail, and it talks about
... and talks about ...
 generic aspects of library programs not specific to Debian.

 Also, please read the Debian Policy carefully,
 and New Maintainer's Guide, and Developers Reference.

... read the respective documentation for packagers. Namely the Debian
Policy the New Maintainer's Guide and the Developers Reference.

[Perhaps collect some crossreferences to the relevant sections about
libraries]

 An experience of having your package broken by some 
 random library upgrade might be a plus.
 
 [Naming library packages]
 
 The policy documents how to name library packages.
   libpackagesoname
 like 
   libc6 for /lib/libc.so.6
 
 However, there are packages which contain libraries that look like this:
 
   /usr/lib/libsomepackage-1.2.so.0
 
 This is a library with a name of libsomepackage-1.2, and a soname of 0.
 The current practice in packaging such package seems to be to have 
   libsomepackage-1.2-0
 as the package name.
 
 It is taking the form of libpackage-soname format
To distinguish the package name and the soname, all library packages with
 to distinguish the package name and the soname, using the -.
a name ending in a numeric, the form libpackage-soname is
 This applies to all library packages which the name ends in a
preferred.
 numeric.

BTW: should't this be libraryname instead of packagename?

 [-DEV package names]
 
 It is ideal to have the soname in the package name, like the following:
 
 Package: libpackage2-dev
 Provides: libpackage-dev
 Conflicts: libpackage-dev
 
 This ensures that only one version of libpackageX-dev
 is installed, and also allows the maintainer of each package
 to selectively link with the expected library with the 
 expected soname version.
 
 It is possible to create 
 Package: libpackage-dev
 and it is allowed by policy. However, this allows
 any version of library libpackage to be linked.
 This has caused much problems, in libpng, and other
 packages. libpackage-dev notation should not be used 
 if it is going to be linked in by other library packages.

Even though the policy allows omitting the soname from the packagename
it is not encouraged, since this has caused much problems as in
libpng-dev and others, which could not live up to the promise of
neverchanging interfaces.

 
 [-DEV package dependencies]
 
 -dev package should depend on all -dev packages that the library
The -dev package should depend on all -dev packages for libraries that the 
library
 package depends upon, with the version that the library package is compiled
package depends upon, with the specific (so)version that the library package is
 against.
compiled against.


 e.g. 
 
 libFOO2-dev - libBAR2-dev
 because libFOO2 depends on libBAR2



 If you want libFOO2-dev that can compile with libBAR3-dev,
 the soname or something else should be fixed. The possible situation
 will be:
 libFOO3-dev - libBAR3-dev
   (discuss with upstream to coordinate the soname change)
 or
 libFOO2-libBAR3-dev - libBAR3-dev
 
 and have libFOO2 

Re: Library packaging

[Jamie Wilkinson]

This one time, at band camp, Junichi Uekawa wrote:
There could, however, be changes in the source
which does affect.

This is true, I feel there are many cases that are not easily tested; so I
will _not_ be trying to make a universal soname checker, guaranteed to work
100%.

I don't know if there could be a systematic way to do it.
Warning might be possible, but not strict and real checking.

Well, for header files I'm thinking of using a parser, then it would be easy
to compare syntax trees of the two versions.

Lintian won't be able to do this, because lintian only has access
to one version of source at the time.

Yes, I'm thinking of a separate program that library maintainers can use.

-- 
[EMAIL PROTECTED]   http://spacepants.org/jaq.gpg
 
liedra yay, there's wmaker for irix
liedra my life is complete ;)
Balial wmaker is pants!
liedra where pants stands for pretty amazingly neat t-something system
-- #sodfest97

Re: Library packaging

[Jamie Wilkinson]

This one time, at band camp, Mark Brown wrote:
That's a first step but it is also possible for there to be incompatible
semantic changes which can't be detected in this fashion.

This is true, but I'm not aiming to make the perfect tool -- I have strong
instincts that the complete problem intractable.

-- 
[EMAIL PROTECTED]   http://spacepants.org/jaq.gpg
 
A user and his leisure time are soon parted.

Re: Library packaging

[Jamie Wilkinson]

This one time, at band camp, Junichi Uekawa wrote:
The upstream may fix the package slightly to make 
binary-incompatible change to the library, and call it
0.3.0 (well, it's only natural).

However, in the library sense, if it is binary-incompatible,
it should have a new soname, i.e. 1.0.0

Are there ways to test libraries against other versions to check for a
binary incompatibility, or does it rely on a human recognising such a
change?

-- 
[EMAIL PROTECTED]   http://spacepants.org/jaq.gpg
 
Words fail me.  Thank goodness I can make gestures.
-- Mark 'Kamikaze' Hughes in the Scary Devil Monastery


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[Junichi Uekawa]

Jamie Wilkinson [EMAIL PROTECTED] cum veritate scripsit:

 However, in the library sense, if it is binary-incompatible,
 it should have a new soname, i.e. 1.0.0
 
 Are there ways to test libraries against other versions to check for a
 binary incompatibility, or does it rely on a human recognising such a
 change?

It does depend on human checking.

A good sign of binary incompatibility include:

Function name change (possible to inspect using objdump -p )
New function/obsolete function symbols
Header file contains definition for structures, and they are changed
function expects different arguments than before



So library package maintainers are somewhat expected to
be monitoring the upstream source difference, or trust
that the upstream does the right thing with it.


There may be more.

# If anyone has a good tool, please tell me.


The best sign of a changed interface are:

o  random segfault
o  irrational behavior



regards,
junihi


-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[Jamie Wilkinson]

This one time, at band camp, Junichi Uekawa wrote:
# If anyone has a good tool, please tell me.

Well, I'm thinking of a way to automate these checks, hence my question.

So, as I understand it, there's an _incompatible_ API change (and thus
requiring a SONAME change) when:

* function prototypes (incl names) that are exported are changed or obsoleted
* structs change or are obsoleted

I think I can see a way to check for both cases, given the old and new
library and header file...  I'll keep you posted.

-- 
[EMAIL PROTECTED]   http://spacepants.org/jaq.gpg
 
Too many clicks spoil the browse.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[Junichi Uekawa]

Jamie Wilkinson [EMAIL PROTECTED] cum veritate scripsit:

 So, as I understand it, there's an _incompatible_ API change (and thus
 requiring a SONAME change) when:
 
 * function prototypes (incl names) that are exported are changed or obsoleted
 * structs change or are obsoleted
 
 I think I can see a way to check for both cases, given the old and new
 library and header file...  I'll keep you posted.

Generally, if a non-comment portion of a header file changes, 
it would be almost safe to assume that the interface has changed.

There could, however, be changes in the source
which does affect.

I don't know if there could be a systematic way to do it.
Warning might be possible, but not strict and real checking.

Lintian won't be able to do this, because lintian only has access
to one version of source at the time.


-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[Mark Brown]

On Mon, Mar 18, 2002 at 12:33:40AM +1100, Jamie Wilkinson wrote:

 So, as I understand it, there's an _incompatible_ API change (and thus
 requiring a SONAME change) when:

 * function prototypes (incl names) that are exported are changed or obsoleted
 * structs change or are obsoleted

 I think I can see a way to check for both cases, given the old and new
 library and header file...  I'll keep you posted.

That's a first step but it is also possible for there to be incompatible
semantic changes which can't be detected in this fashion.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.



msg05741/pgp0.pgp
Description: PGP signature

updated library packaging FAQ(Re: Library packaging)

[Junichi Uekawa]

Junichi Uekawa [EMAIL PROTECTED] cum veritate scripsit:

Well, now I updated the doc a little bit, I'll post it here.
I've received exactly one response so far, and I'm feeling a bit
naive about the contents of this document.
Please comment:

Library packaging Guide (very much a draft).
This is just something to get the ball rolling, not the definitive guide.

10 Jan 2002, 13 Jan 2002. Junichi Uekawa.
Revised to be up-to-date on 17 Mar 2002.
Distributed under the terms of GPL version 2 or later


This guide tries to make the problems related with 
library packaging to be clear to the Developers of Debian Project,
to hopefully raise the general awareness, and to fill the gap of
Debian documentation lacking in the direction of library package.

Hopefully this document will be more accurate as criticisms come, 
and will improve the general quality of Debian,
and provide a good reading for newbie Debian developers,
instead of the don't even dare packaging libraries if you 
are a newbie guide.

[Traits of Debian]

First, let us check what Debian is in the perspective of 
maintaining library packages, and why Debian is different to 
other systems.

Debian is a binary-distribution-centric system.
Binary is created from source, and they are the ones that 
gets distributed mainly.
Binary is compiled from the source at time as a snapshot for one architecture,
and several copies of binary is built from the same source at different points
for different architectures, against different versions of the library
that may exist at that point.

Thus, unless one is careful, one has no control over which version of 
specific development package a binary will be compiled with.

Debian has a packaging scheme for libraries, with having
libfooX package for run-time required library files,
and libfooX-dev package for buid-time required library files.


[Recommended reading before doing library packages]

It is recommended to read the info page for libtool,
which is contained in the libtool-doc package.
It explains many things in detail, and it talks about
generic aspects of library programs not specific to Debian.

Also, please read the Debian Policy carefully,
and New Maintainer's Guide, and Developers Reference.
An experience of having your package broken by some 
random library upgrade might be a plus.

[Naming library packages]

The policy documents how to name library packages.
  libpackagesoname
like 
  libc6 for /lib/libc.so.6

However, there are packages which contain libraries that look like this:

  /usr/lib/libsomepackage-1.2.so.0

This is a library with a name of libsomepackage-1.2, and a soname of 0.
The current practice in packaging such package seems to be to have 
  libsomepackage-1.2-0
as the package name.

It is taking the form of libpackage-soname format
to distinguish the package name and the soname, using the -.
This applies to all library packages which the name ends in a
numeric.

[-DEV package names]

It is ideal to have the soname in the package name, like the following:

Package: libpackage2-dev
Provides: libpackage-dev
Conflicts: libpackage-dev

This ensures that only one version of libpackageX-dev
is installed, and also allows the maintainer of each package
to selectively link with the expected library with the 
expected soname version.

It is possible to create 
Package: libpackage-dev
and it is allowed by policy. However, this allows
any version of library libpackage to be linked.
This has caused much problems, in libpng, and other
packages. libpackage-dev notation should not be used 
if it is going to be linked in by other library packages.


[-DEV package dependencies]

-dev package should depend on all -dev packages that the library
package depends upon, with the version that the library package is compiled
against.

e.g. 

libFOO2-dev - libBAR2-dev
because libFOO2 depends on libBAR2

If you want libFOO2-dev that can compile with libBAR3-dev,
the soname or something else should be fixed. The possible situation
will be:
libFOO3-dev - libBAR3-dev
  (discuss with upstream to coordinate the soname change)
or
libFOO2-libBAR3-dev - libBAR3-dev

and have libFOO2 and libFOO2-libBAR3 conflicting with each other.


[Packages which Build-depend on a -DEV package]

It is advised to

Build-Depend: libpackagesoname-dev | libpackage-dev 
(this can cause undesired effect of linking with a source-incompatible 
 library version, i.e. a serious cannot build from source bug)

or

Build-Depend: libpackagesoname-dev
(This needs to be updated every time a new -dev comes out, and 
the new soname becomes the standard, and the old one becomes obsolete)

[WHY Build-Depend: libpackage-dev IS NOT OPTIMAL]

Answer the following question:
Are you really sure all past/present/future version of that 
-dev package can be used with the source to build the package?


[SONAMES]

If a package version matches the soname.
scrap it, and bash the upstream with the libtool manual.
It is usually a good sign that either he has not read

Re: Library packaging

[Jamie Wilkinson]

This one time, at band camp, Junichi Uekawa wrote:
The upstream may fix the package slightly to make 
binary-incompatible change to the library, and call it
0.3.0 (well, it's only natural).

However, in the library sense, if it is binary-incompatible,
it should have a new soname, i.e. 1.0.0

Are there ways to test libraries against other versions to check for a
binary incompatibility, or does it rely on a human recognising such a
change?

-- 
[EMAIL PROTECTED]   http://spacepants.org/jaq.gpg
 
Words fail me.  Thank goodness I can make gestures.
-- Mark 'Kamikaze' Hughes in the Scary Devil Monastery

Re: Library packaging

[Junichi Uekawa]

Jamie Wilkinson [EMAIL PROTECTED] cum veritate scripsit:

 However, in the library sense, if it is binary-incompatible,
 it should have a new soname, i.e. 1.0.0
 
 Are there ways to test libraries against other versions to check for a
 binary incompatibility, or does it rely on a human recognising such a
 change?

It does depend on human checking.

A good sign of binary incompatibility include:

Function name change (possible to inspect using objdump -p )
New function/obsolete function symbols
Header file contains definition for structures, and they are changed
function expects different arguments than before



So library package maintainers are somewhat expected to
be monitoring the upstream source difference, or trust
that the upstream does the right thing with it.


There may be more.

# If anyone has a good tool, please tell me.


The best sign of a changed interface are:

o  random segfault
o  irrational behavior



regards,
junihi


-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

Re: Library packaging

[Jamie Wilkinson]

This one time, at band camp, Junichi Uekawa wrote:
# If anyone has a good tool, please tell me.

Well, I'm thinking of a way to automate these checks, hence my question.

So, as I understand it, there's an _incompatible_ API change (and thus
requiring a SONAME change) when:

* function prototypes (incl names) that are exported are changed or obsoleted
* structs change or are obsoleted

I think I can see a way to check for both cases, given the old and new
library and header file...  I'll keep you posted.

-- 
[EMAIL PROTECTED]   http://spacepants.org/jaq.gpg
 
Too many clicks spoil the browse.

Re: Library packaging

[Junichi Uekawa]

Jamie Wilkinson [EMAIL PROTECTED] cum veritate scripsit:

 So, as I understand it, there's an _incompatible_ API change (and thus
 requiring a SONAME change) when:
 
 * function prototypes (incl names) that are exported are changed or obsoleted
 * structs change or are obsoleted
 
 I think I can see a way to check for both cases, given the old and new
 library and header file...  I'll keep you posted.

Generally, if a non-comment portion of a header file changes, 
it would be almost safe to assume that the interface has changed.

There could, however, be changes in the source
which does affect.

I don't know if there could be a systematic way to do it.
Warning might be possible, but not strict and real checking.

Lintian won't be able to do this, because lintian only has access
to one version of source at the time.


-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

Re: Library packaging

[Mark Brown]

On Mon, Mar 18, 2002 at 12:33:40AM +1100, Jamie Wilkinson wrote:

 So, as I understand it, there's an _incompatible_ API change (and thus
 requiring a SONAME change) when:

 * function prototypes (incl names) that are exported are changed or obsoleted
 * structs change or are obsoleted

 I think I can see a way to check for both cases, given the old and new
 library and header file...  I'll keep you posted.

That's a first step but it is also possible for there to be incompatible
semantic changes which can't be detected in this fashion.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


pgpgurV3I9xh4.pgp
Description: PGP signature

updated library packaging FAQ(Re: Library packaging)

[Junichi Uekawa]

Junichi Uekawa [EMAIL PROTECTED] cum veritate scripsit:

Well, now I updated the doc a little bit, I'll post it here.
I've received exactly one response so far, and I'm feeling a bit
naive about the contents of this document.
Please comment:

Library packaging Guide (very much a draft).
This is just something to get the ball rolling, not the definitive guide.

10 Jan 2002, 13 Jan 2002. Junichi Uekawa.
Revised to be up-to-date on 17 Mar 2002.
Distributed under the terms of GPL version 2 or later


This guide tries to make the problems related with 
library packaging to be clear to the Developers of Debian Project,
to hopefully raise the general awareness, and to fill the gap of
Debian documentation lacking in the direction of library package.

Hopefully this document will be more accurate as criticisms come, 
and will improve the general quality of Debian,
and provide a good reading for newbie Debian developers,
instead of the don't even dare packaging libraries if you 
are a newbie guide.

[Traits of Debian]

First, let us check what Debian is in the perspective of 
maintaining library packages, and why Debian is different to 
other systems.

Debian is a binary-distribution-centric system.
Binary is created from source, and they are the ones that 
gets distributed mainly.
Binary is compiled from the source at time as a snapshot for one architecture,
and several copies of binary is built from the same source at different points
for different architectures, against different versions of the library
that may exist at that point.

Thus, unless one is careful, one has no control over which version of 
specific development package a binary will be compiled with.

Debian has a packaging scheme for libraries, with having
libfooX package for run-time required library files,
and libfooX-dev package for buid-time required library files.


[Recommended reading before doing library packages]

It is recommended to read the info page for libtool,
which is contained in the libtool-doc package.
It explains many things in detail, and it talks about
generic aspects of library programs not specific to Debian.

Also, please read the Debian Policy carefully,
and New Maintainer's Guide, and Developers Reference.
An experience of having your package broken by some 
random library upgrade might be a plus.

[Naming library packages]

The policy documents how to name library packages.
  libpackagesoname
like 
  libc6 for /lib/libc.so.6

However, there are packages which contain libraries that look like this:

  /usr/lib/libsomepackage-1.2.so.0

This is a library with a name of libsomepackage-1.2, and a soname of 0.
The current practice in packaging such package seems to be to have 
  libsomepackage-1.2-0
as the package name.

It is taking the form of libpackage-soname format
to distinguish the package name and the soname, using the -.
This applies to all library packages which the name ends in a
numeric.

[-DEV package names]

It is ideal to have the soname in the package name, like the following:

Package: libpackage2-dev
Provides: libpackage-dev
Conflicts: libpackage-dev

This ensures that only one version of libpackageX-dev
is installed, and also allows the maintainer of each package
to selectively link with the expected library with the 
expected soname version.

It is possible to create 
Package: libpackage-dev
and it is allowed by policy. However, this allows
any version of library libpackage to be linked.
This has caused much problems, in libpng, and other
packages. libpackage-dev notation should not be used 
if it is going to be linked in by other library packages.


[-DEV package dependencies]

-dev package should depend on all -dev packages that the library
package depends upon, with the version that the library package is compiled
against.

e.g. 

libFOO2-dev - libBAR2-dev
because libFOO2 depends on libBAR2

If you want libFOO2-dev that can compile with libBAR3-dev,
the soname or something else should be fixed. The possible situation
will be:
libFOO3-dev - libBAR3-dev
  (discuss with upstream to coordinate the soname change)
or
libFOO2-libBAR3-dev - libBAR3-dev

and have libFOO2 and libFOO2-libBAR3 conflicting with each other.


[Packages which Build-depend on a -DEV package]

It is advised to

Build-Depend: libpackagesoname-dev | libpackage-dev 
(this can cause undesired effect of linking with a source-incompatible 
 library version, i.e. a serious cannot build from source bug)

or

Build-Depend: libpackagesoname-dev
(This needs to be updated every time a new -dev comes out, and 
the new soname becomes the standard, and the old one becomes obsolete)

[WHY Build-Depend: libpackage-dev IS NOT OPTIMAL]

Answer the following question:
Are you really sure all past/present/future version of that 
-dev package can be used with the source to build the package?


[SONAMES]

If a package version matches the soname.
scrap it, and bash the upstream with the libtool manual.
It is usually a good sign that either he has not read

Re: Library packaging

[peter karlsson]

Junichi Uekawa:

 That doesn't tell much.
 objdump -p /usr/lib/libMowitz.so | grep SONAME

er$ objdump -p /usr/lib/libMowitz.so | grep SONAME
  SONAME  libMowitz.so.0

 That sounds like a bad news, a potential sign of upstream changing
 binary interface between 0.1.0 and 0.2.0

I don't know...

-- 
\\//
peter - I do not read or respond to mail with HTML attachments.
  Statement concerning unsolicited e-mail according to Swedish law:
  http://www.softwolves.pp.se/peter/reklampost.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[Junichi Uekawa]

peter karlsson [EMAIL PROTECTED] cum veritate scripsit:

  That sounds like a bad news, a potential sign of upstream changing
  binary interface between 0.1.0 and 0.2.0
 
 I don't know...


The upstream may fix the package slightly to make 
binary-incompatible change to the library, and call it
0.3.0 (well, it's only natural).

However, in the library sense, if it is binary-incompatible,
it should have a new soname, i.e. 1.0.0



regards,
junichi


-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[peter karlsson]

Junichi Uekawa:

 That doesn't tell much.
 objdump -p /usr/lib/libMowitz.so | grep SONAME

er$ objdump -p /usr/lib/libMowitz.so | grep SONAME
  SONAME  libMowitz.so.0

 That sounds like a bad news, a potential sign of upstream changing
 binary interface between 0.1.0 and 0.2.0

I don't know...

-- 
\\//
peter - I do not read or respond to mail with HTML attachments.
  Statement concerning unsolicited e-mail according to Swedish law:
  http://www.softwolves.pp.se/peter/reklampost.html

Re: Library packaging

[Junichi Uekawa]

peter karlsson [EMAIL PROTECTED] cum veritate scripsit:

  That sounds like a bad news, a potential sign of upstream changing
  binary interface between 0.1.0 and 0.2.0
 
 I don't know...


The upstream may fix the package slightly to make 
binary-incompatible change to the library, and call it
0.3.0 (well, it's only natural).

However, in the library sense, if it is binary-incompatible,
it should have a new soname, i.e. 1.0.0



regards,
junichi


-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

Re: Library packaging

[Junichi Uekawa]

peter karlsson [EMAIL PROTECTED] cum veritate scripsit:

  Binary package names are incorrect, name them libmowitz0 and
  libmowitz-dev
 
 Okay. I was a bit uncertain about that. I just used the names that
 dh_make used.


If that's the case, I also have doubts whether it should be 
called libmowitz0

Are you sure of the soname version number?


regards,
junichi

-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[peter karlsson]

Junichi Uekawa:

 Are you sure of the soname version number?

It is at least the version used in the files:

$ ls -l /usr/lib/libMowitz.*
-rw-r--r--1 root root   400490 13 mar 18.42 /usr/lib/libMowitz.a
-rw-r--r--1 root root  717 13 mar 18.41 /usr/lib/libMowitz.la
lrwxrwxrwx1 root root   18 13 mar 18.44 /usr/lib/libMowitz.so - 
libMowitz.so.0.2.0
lrwxrwxrwx1 root root   18 13 mar 18.43 /usr/lib/libMowitz.so.0 - 
libMowitz.so.0.2.0
-rw-r--r--1 root root   296592 13 mar 18.42 /usr/lib/libMowitz.so.0.2.0

And the version number of the package is 0.2.0 as well.

-- 
\\//
peter - I do not read or respond to mail with HTML attachments.
  Statement concerning unsolicited e-mail according to Swedish law:
  http://www.softwolves.pp.se/peter/reklampost.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[Junichi Uekawa]

peter karlsson [EMAIL PROTECTED] cum veritate scripsit:

  Binary package names are incorrect, name them libmowitz0 and
  libmowitz-dev
 
 Okay. I was a bit uncertain about that. I just used the names that
 dh_make used.


If that's the case, I also have doubts whether it should be 
called libmowitz0

Are you sure of the soname version number?


regards,
junichi

-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

Re: Library packaging

[peter karlsson]

Junichi Uekawa:

 Are you sure of the soname version number?

It is at least the version used in the files:

$ ls -l /usr/lib/libMowitz.*
-rw-r--r--1 root root   400490 13 mar 18.42 /usr/lib/libMowitz.a
-rw-r--r--1 root root  717 13 mar 18.41 /usr/lib/libMowitz.la
lrwxrwxrwx1 root root   18 13 mar 18.44 /usr/lib/libMowitz.so 
- libMowitz.so.0.2.0
lrwxrwxrwx1 root root   18 13 mar 18.43 /usr/lib/libMowitz.so.0 
- libMowitz.so.0.2.0
-rw-r--r--1 root root   296592 13 mar 18.42 
/usr/lib/libMowitz.so.0.2.0

And the version number of the package is 0.2.0 as well.

-- 
\\//
peter - I do not read or respond to mail with HTML attachments.
  Statement concerning unsolicited e-mail according to Swedish law:
  http://www.softwolves.pp.se/peter/reklampost.html

Re: Library packaging

[Junichi Uekawa]

peter karlsson [EMAIL PROTECTED] cum veritate scripsit:

 $ ls -l /usr/lib/libMowitz.*
 -rw-r--r--1 root root   400490 13 mar 18.42 /usr/lib/libMowitz.a
 -rw-r--r--1 root root  717 13 mar 18.41 /usr/lib/libMowitz.la
 lrwxrwxrwx1 root root   18 13 mar 18.44 /usr/lib/libMowitz.so 
 - libMowitz.so.0.2.0
 lrwxrwxrwx1 root root   18 13 mar 18.43 
 /usr/lib/libMowitz.so.0 - libMowitz.so.0.2.0

That doesn't tell much.
objdump -p /usr/lib/libMowitz.so | grep SONAME


 -rw-r--r--1 root root   296592 13 mar 18.42 
 /usr/lib/libMowitz.so.0.2.0
 
 And the version number of the package is 0.2.0 as well.

That sounds like a bad news, a potential sign of
upstream changing binary interface between 0.1.0 and 0.2.0

regards,
junichi

-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

Re: Library packaging

[Junichi Uekawa]

peter karlsson [EMAIL PROTECTED] cum veritate scripsit:

 Could someone please have a look at the files that I put up at
 http://www.softwolves.pp.se/tmp/mowitz/ and see if I have done it right
 or not?

Without too much looking at, my first question is:
why do you have mowitz-config in diff.gz?

Binary package names are incorrect, name them
libmowitz0 and libmowitz-dev
The source package name is fine.


regards,
junichi

-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[peter karlsson]

Junichi Uekawa:

 Without too much looking at, my first question is: why do you have
 mowitz-config in diff.gz?

It seems that it is not removed properly when doing a make distclean.
I'll fix that.

 Binary package names are incorrect, name them libmowitz0 and
 libmowitz-dev

Okay. I was a bit uncertain about that. I just used the names that
dh_make used.

-- 
\\//
peter - http://www.softwolves.pp.se/

  I do not read or respond to mail with HTML attachments.
  Statement concerning unsolicited e-mail according to Swedish law:
  http://www.softwolves.pp.se/peter/reklampost.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Library packaging

[peter karlsson]

Hi!

When upgrading Siag Office to its latest version I found that parts of
the code had been broken out into a library. Since I have never before
packaged a library I would appreciate some help to check whether I am
doing things correctly or not.

Could someone please have a look at the files that I put up at
http://www.softwolves.pp.se/tmp/mowitz/ and see if I have done it right
or not?

Thanks in advance,
-- 
\\//
peter - http://www.softwolves.pp.se/

  I do not read or respond to mail with HTML attachments.
  Statement concerning unsolicited e-mail according to Swedish law:
  http://www.softwolves.pp.se/peter/reklampost.html

Re: Library packaging

[Junichi Uekawa]

peter karlsson [EMAIL PROTECTED] cum veritate scripsit:

 Could someone please have a look at the files that I put up at
 http://www.softwolves.pp.se/tmp/mowitz/ and see if I have done it right
 or not?

Without too much looking at, my first question is:
why do you have mowitz-config in diff.gz?

Binary package names are incorrect, name them
libmowitz0 and libmowitz-dev
The source package name is fine.


regards,
junichi

-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

Re: Library packaging

[peter karlsson]

Junichi Uekawa:

 Without too much looking at, my first question is: why do you have
 mowitz-config in diff.gz?

It seems that it is not removed properly when doing a make distclean.
I'll fix that.

 Binary package names are incorrect, name them libmowitz0 and
 libmowitz-dev

Okay. I was a bit uncertain about that. I just used the names that
dh_make used.

-- 
\\//
peter - http://www.softwolves.pp.se/

  I do not read or respond to mail with HTML attachments.
  Statement concerning unsolicited e-mail according to Swedish law:
  http://www.softwolves.pp.se/peter/reklampost.html

Library packaging

[Sam Couter]

I'm a fairly new maintainer, and I have a few questions about packaging
libraries.

I'm trying to package NJAMD. It's a malloc debugging library, similar in
some ways to ElectricFence or dmalloc.

NJAMD works by being loaded with LD_PRELOAD. The normal package contains a
shared object (libnjamd.so.0.0.8) and two symlinks to it (libnjamd.so.0 and
libnjamd.so), just like most shared objects.

The packaging manual says that the libnjamd.so symlink should go in the -dev
package, with the headers and such.
There aren't any headers.

I've just had the package rejected by the ftpmasters because it has the
symlink in the njamd package, and there is no -dev package.

Am I really expected to create a -dev package with just one symlink in it?

I tried to use the electric-fence and dmalloc packages as examples to
follow. Neither are named libwhatever, both contain shared objects. dmalloc
has no .so symlink, just libdmalloc.so.4.2 or something. electric-fence does
have a .so symlink, but it's also only an old policy version.

Can someone with more experience, or better understanding of the packaging
manual and policy, please help me out here?

Thanks.
-- 
Sam Couter  |   Internet Engineer   |   http://www.topic.com.au/
[EMAIL PROTECTED]|   tSA Consulting  |
OpenPGP key ID:   DE89C75C,  available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

 PGP signature

Re: Library packaging

[Ove Kaaven]

On Sat, 3 Mar 2001, Sam Couter wrote:

 I tried to use the electric-fence and dmalloc packages as examples to
 follow. Neither are named libwhatever, both contain shared objects. dmalloc
 has no .so symlink, just libdmalloc.so.4.2 or something. electric-fence does
 have a .so symlink, but it's also only an old policy version.

For yet another example, look at debauch, which does pretty much exactly
what you want to do... (and it seems to give that lintian warning too,
hmm.)


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[Josip Rodin]

On Sat, Mar 03, 2001 at 11:08:37PM +1100, Sam Couter wrote:
 NJAMD works by being loaded with LD_PRELOAD. The normal package contains a
 shared object (libnjamd.so.0.0.8) and two symlinks to it (libnjamd.so.0 and
 libnjamd.so), just like most shared objects.

Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and
you'll be fine. No symlinks are necessary I'd think.

Make sure it's documented, too.

-- 
Digital Electronic Being Intended for Assassination and Nullification


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[Michael Beattie]

On Sat, Mar 03, 2001 at 07:56:39PM +0100, Josip Rodin wrote:
 On Sat, Mar 03, 2001 at 11:08:37PM +1100, Sam Couter wrote:
  NJAMD works by being loaded with LD_PRELOAD. The normal package contains a
  shared object (libnjamd.so.0.0.8) and two symlinks to it (libnjamd.so.0 and
  libnjamd.so), just like most shared objects.
 
 Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and
 you'll be fine. No symlinks are necessary I'd think.

exactly why I rejected it.

Mike.
-- 

  Michael Beattie ([EMAIL PROTECTED])

 -
 yip yip yip yip yip yip yap yap yip *BANG* NO TERRIER
 -
Debian GNU/Linux  Ooohh You are missing out!


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Library packaging

[Sam Couter]

Josip Rodin [EMAIL PROTECTED] wrote:
 
 Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and
 you'll be fine. No symlinks are necessary I'd think.

More details are in order, I think.

To use the library, you use a command line something like:

LD_PRELOAD=libnjamd.so program_to_debug

If the library is in some directory other than a normal library directory,
the full path will have to go in the LD_PRELOAD variable, or LD_LIBRARY_PATH
will need to be set as well.

That's not very convenient, and in fact is the main reason why I want to
package it at all (I got sick of typing
LD_PRELOAD=/home/sam/njamd/lib/libnjamd.so all the time).

If the .so symlink is not included, the version of the NJAMD library to use
will also need to go in the LD_PRELOAD variable. That's not just
inconvenient, it's insane.

Another example of a similar package, as someone on this list pointed out,
is debauch. It has a .so symlink in /usr/lib as well, and a recent policy
version.

 Make sure it's documented, too.

Obviously, otherwise it'd be pretty useless. :)
-- 
Sam Couter  |   Internet Engineer   |   http://www.topic.com.au/
[EMAIL PROTECTED]|   tSA Consulting  |
OpenPGP key ID:   DE89C75C,  available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

 PGP signature

Re: Library packaging

[Josip Rodin]

On Sun, Mar 04, 2001 at 11:39:46AM +1100, Sam Couter wrote:
  Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and
  you'll be fine. No symlinks are necessary I'd think.
 
 If the library is in some directory other than a normal library directory,
 the full path will have to go in the LD_PRELOAD variable, or LD_LIBRARY_PATH
 will need to be set as well.

Ah, okay.

Since this library wouldn't get linked to like others would, how do you deal
with the issue of (not) having a shlibs file and (not) invoking ldconfig?

 If the .so symlink is not included, the version of the NJAMD library to use
 will also need to go in the LD_PRELOAD variable. That's not just
 inconvenient, it's insane.

I didn't mean that, I meant that you can make the real file be called
libfoo.so and that's it. Unless of course the version in the file name is
necessary?

It doesn't look like this is covered in Policy or FHS...

-- 
Digital Electronic Being Intended for Assassination and Nullification


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Library packaging

[Sam Couter]

I'm a fairly new maintainer, and I have a few questions about packaging
libraries.

I'm trying to package NJAMD. It's a malloc debugging library, similar in
some ways to ElectricFence or dmalloc.

NJAMD works by being loaded with LD_PRELOAD. The normal package contains a
shared object (libnjamd.so.0.0.8) and two symlinks to it (libnjamd.so.0 and
libnjamd.so), just like most shared objects.

The packaging manual says that the libnjamd.so symlink should go in the -dev
package, with the headers and such.
There aren't any headers.

I've just had the package rejected by the ftpmasters because it has the
symlink in the njamd package, and there is no -dev package.

Am I really expected to create a -dev package with just one symlink in it?

I tried to use the electric-fence and dmalloc packages as examples to
follow. Neither are named libwhatever, both contain shared objects. dmalloc
has no .so symlink, just libdmalloc.so.4.2 or something. electric-fence does
have a .so symlink, but it's also only an old policy version.

Can someone with more experience, or better understanding of the packaging
manual and policy, please help me out here?

Thanks.
-- 
Sam Couter  |   Internet Engineer   |   http://www.topic.com.au/
[EMAIL PROTECTED]|   tSA Consulting  |
OpenPGP key ID:   DE89C75C,  available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C


pgp0Ix1zclWA8.pgp
Description: PGP signature

Re: Library packaging

[Ove Kaaven]

On Sat, 3 Mar 2001, Sam Couter wrote:

 I tried to use the electric-fence and dmalloc packages as examples to
 follow. Neither are named libwhatever, both contain shared objects. dmalloc
 has no .so symlink, just libdmalloc.so.4.2 or something. electric-fence does
 have a .so symlink, but it's also only an old policy version.

For yet another example, look at debauch, which does pretty much exactly
what you want to do... (and it seems to give that lintian warning too,
hmm.)

Re: Library packaging

[Josip Rodin]

On Sat, Mar 03, 2001 at 11:08:37PM +1100, Sam Couter wrote:
 NJAMD works by being loaded with LD_PRELOAD. The normal package contains a
 shared object (libnjamd.so.0.0.8) and two symlinks to it (libnjamd.so.0 and
 libnjamd.so), just like most shared objects.

Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and
you'll be fine. No symlinks are necessary I'd think.

Make sure it's documented, too.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: Library packaging

[Michael Beattie]

On Sat, Mar 03, 2001 at 07:56:39PM +0100, Josip Rodin wrote:
 On Sat, Mar 03, 2001 at 11:08:37PM +1100, Sam Couter wrote:
  NJAMD works by being loaded with LD_PRELOAD. The normal package contains a
  shared object (libnjamd.so.0.0.8) and two symlinks to it (libnjamd.so.0 and
  libnjamd.so), just like most shared objects.
 
 Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and
 you'll be fine. No symlinks are necessary I'd think.

exactly why I rejected it.

Mike.
-- 

  Michael Beattie ([EMAIL PROTECTED])

 -
 yip yip yip yip yip yip yap yap yip *BANG* NO TERRIER
 -
Debian GNU/Linux  Ooohh You are missing out!

Re: Library packaging

[Sam Couter]

Josip Rodin [EMAIL PROTECTED] wrote:
 
 Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and
 you'll be fine. No symlinks are necessary I'd think.

More details are in order, I think.

To use the library, you use a command line something like:

LD_PRELOAD=libnjamd.so program_to_debug

If the library is in some directory other than a normal library directory,
the full path will have to go in the LD_PRELOAD variable, or LD_LIBRARY_PATH
will need to be set as well.

That's not very convenient, and in fact is the main reason why I want to
package it at all (I got sick of typing
LD_PRELOAD=/home/sam/njamd/lib/libnjamd.so all the time).

If the .so symlink is not included, the version of the NJAMD library to use
will also need to go in the LD_PRELOAD variable. That's not just
inconvenient, it's insane.

Another example of a similar package, as someone on this list pointed out,
is debauch. It has a .so symlink in /usr/lib as well, and a recent policy
version.

 Make sure it's documented, too.

Obviously, otherwise it'd be pretty useless. :)
-- 
Sam Couter  |   Internet Engineer   |   http://www.topic.com.au/
[EMAIL PROTECTED]|   tSA Consulting  |
OpenPGP key ID:   DE89C75C,  available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C


pgpHd0TQkb0q4.pgp
Description: PGP signature

Re: Library packaging

[Josip Rodin]

On Sun, Mar 04, 2001 at 11:39:46AM +1100, Sam Couter wrote:
  Just put the file in a private directory (i.e. /usr/lib/njamd/ or so) and
  you'll be fine. No symlinks are necessary I'd think.
 
 If the library is in some directory other than a normal library directory,
 the full path will have to go in the LD_PRELOAD variable, or LD_LIBRARY_PATH
 will need to be set as well.

Ah, okay.

Since this library wouldn't get linked to like others would, how do you deal
with the issue of (not) having a shlibs file and (not) invoking ldconfig?

 If the .so symlink is not included, the version of the NJAMD library to use
 will also need to go in the LD_PRELOAD variable. That's not just
 inconvenient, it's insane.

I didn't mean that, I meant that you can make the real file be called
libfoo.so and that's it. Unless of course the version in the file name is
necessary?

It doesn't look like this is covered in Policy or FHS...

-- 
Digital Electronic Being Intended for Assassination and Nullification

library packaging howto?

[Will Lowe]

I've been around for a while,  I have a couple of packages.  I'm about to
undertake packaging my first set of libraries,  and I'm not sure what's
different.  I understand that a stripped copy of the library goes into the 
{package}lib.deb,  and that a debugging-enabled copy (and header files) go
into {package}lib-dev.deb,  but what else do I need to do?

Will


--
| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]   |
|   http://www.cis.udel.edu/~lowe/   |
|PGP Public Key:  http://www.cis.udel.edu/~lowe/index.html#pgpkey|
--
|   You think you're so smart,  but I've seen you naked  |
|  and I'll prob'ly see you naked again ...  |
| --The Barenaked Ladies,  Blame It On Me  |
--

Re: library packaging howto?

[Ben Gertzfield]

 Will == Will Lowe [EMAIL PROTECTED] writes:

Will I've been around for a while, I have a couple of packages.
Will I'm about to undertake packaging my first set of libraries,
Will and I'm not sure what's different.  I understand that a
Will stripped copy of the library goes into the {package}lib.deb,
Will and that a debugging-enabled copy (and header files) go into
Will {package}lib-dev.deb, but what else do I need to do?

Pretty much it's a matter of looking at an existing package -- that's
how you learn.

Take a peek at bash's debian/rules file to see how it does
libreadline, or look at libgtk1's debian/* files to see how a pure
library package is handled.

The short is:

.so.1 and .so.1.0.0 go into libblah1
.so and .a and .h files go into libblah-dev
(optional) debugging-enabled .a goes into libblah-dbg

Your numbers may vary.

-- 
Brought to you by the letters N and I and the number 11.
Ha ha! I have evaded you with the aid of these pasty white mints!
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.

Re: library packaging howto?

[Ben Gertzfield]

 Josip == Josip Rodin [EMAIL PROTECTED] writes:

Ben The short is:
Ben 
Ben .so.1 and .so.1.0.0 go into libblah1 .so and .a and .h files
Ben go into libblah-dev (optional) debugging-enabled .a goes into
Ben libblah-dbg
Ben 
Ben Your numbers may vary.

Josip I think I saw somewhere a library that did not have
Josip libblah.so as an actual file, but a symlink to
Josip libblah.1.0.0 (which was a file, of course :) Is it
Josip possible, and what to do then?

Ack! I'm sorry.

Only the .so.1.0.0 file will be an actual file.

The .so.1 and .so files *will* be symlinks.

Josip Also, libblah1 goes to libs section, and -dev and -dbg into
Josip devel section, right? If so, libfltk-dev is misplaced.
Josip FWIW I'd like -devs in libs section.

There isn't policy (unfortunately) but yes, that's the accepted
standard.

-- 
Brought to you by the letters W and J and the number 16.
It is sad. *Campers* cannot *dance*. Not even a *party*.
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.

Re: library packaging howto?

[Josip Rodin]

On Fri, Jan 08, 1999 at 02:36:57PM -0800, Ben Gertzfield wrote:
 Josip Also, libblah1 goes to libs section, and -dev and -dbg into
 Josip devel section, right? If so, libfltk-dev is misplaced.
 Josip FWIW I'd like -devs in libs section.
 
 There isn't policy (unfortunately) but yes, that's the accepted
 standard.

Really? So lets write one, for inclusion in debian-policy or
developers-reference.

--
enJoy -*/\*- http://jagor.srce.hr/~jrodin/