RFS: wcslib
Dear mentors, I am looking for a sponsor for my package wcslib. * Package name: wcslib Version : 4.8.1-1 Upstream Author : Mark Calabretta mcala...@atnf.csiro.au * URL : http://www.atnf.csiro.au/people/mcalabre/WCS/ * License : LGPLv3+ Section : science It builds those binary packages: libwcs4- Implementation of the FITS WCS standard wcslib-dev - Header files and static library for wcslib wcslib-doc - API documentation for wcslib wcslib-tools - Command line tools utilizing wcslib To access further information about this package, please visit the following URL: http://mentors.debian.net/package/wcslib Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/w/wcslib/wcslib_4.8.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Ole Streicher -- 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/87r536m8ns@news.ole.ath.cx
Shared libs dependencies
Dear list, I am a bit confused about how I have to declare the dependencies when creating a shared library package. I've read the Debian Policy Manual; however I do not now understand what to do. First of all: what is the difference between the Depends field in the control file and the shlibs file? Should they contain the same (library) dependencies? My source package (wcslib) will create a shared library package libwcs4 and a tools package wcslib-tools (and others). So, since I have multiple binary pkgs, I should (according to the manual) create a file debian/shlibs.libwcs4 containing the library that libwcs4 depends on; in my case (it depends on libcfitsio): --8- libwcs 4 libcfitsio3 libc6 libm6 --8- (do I need to specify libc and libm?) Then, I should install this in my installation rule in debian/rules. Since I have still no specific installation rule, I would need to put the following rule to debian/rules, right? -8- override_dh_install: dh_install debian/shlibs.libwcs4 debian/libwcs4/DEBIAN/shlibs -8- Since zlib was used as an example in the manual, I downloaded the debian.tar.gz of zlib to explore this rule, but I could not find it -- I could not find anything related to shlib?? Then, the policy manual states that I have to put a a call to dpkg-shlibdeps into my debian/rules file, but to which rule do I have to add this? In my case, these calls would probably be -8- dpkg-shlibdeps -T debian/substvars.libwcs4 debian/tmp/usr/lib/libwcs.so.4.8.1 dpkg-shlibdeps -T debian/substvars.wcslib-tools debian/tmp/usr/bin/* -8- Manually calling dpkg-shlibdeps libwcs.so.4.8.1 brings warnings like dpkg-shlibdeps: warning: binaries to analyze should already be installed in their package's directory. dpkg-shlibdeps: warning: symbol fmod used by debian/tmp/usr/lib/libwcs.so found in none of the libraries. and a few other complaints about symbols from libm. Shall I take these warnings serious? A last question: If I ignore the shared lib chapter of the policy manual completely, lintian does not complain with the default settings. However, with the -I option, I get the informational I: libwcs4: no-symbols-control-file usr/lib/libwcs.so.4.8.1 Should I care now about this and if yes, how do I solve this? Sorry if this post looks stupid; but I feel a bit lost in the moment between the different Debian tools for the shared library creation (and this is my very first package for Debian). Best regards Ole -- 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/ytzr5371oei@news.ole.ath.cx
Re: Package separation/naming conventions
Gergely Nagy alger...@balabit.hu writes: * Either don't build the part which (build-)depends on non-free, and don't ship it at all, then both the source and the resulting binaries can be in main. I will probably go with this option. If one really needs the libpgsbox, I would create a completely new source package (with the same upstream tar), and just pack the pgsbox stuff. So, I would get the following packages: wcslib ... source package libwcs4 .. shared library wcslib-dev ... static library and header wcslib-doc ... API documentation wcslib-tools . tools built with wcslib My question is not the naming of the binary packages. The original library is called wcslib, and to maximize confusion, there exists somewhere else another (not compatible, less used) library for the same task, called libwcs, which is part of a wcstools package. To avoid naming confusion, I would like to name all packages wcslib; however lintian doesn't like my idea to call the shared library package wcslib4. Can/should I ignore this warning since I have a reason to do so? I found some other packages (namely zlib1g) where the package name does not match the soname. And if I shall use libwcs4; should I then also use libwcs-dev, libwcs-doc and libwcs-tools for the other binary packages? Best regards Ole -- 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/ytzmxdv1ndp@news.ole.ath.cx
Re: Shared libs dependencies
Gergely Nagy alger...@balabit.hu writes: Or, to put it in other words: Depends lists the packages your library depends on, shlibs lists the libs that packages built against your lib should depend on. So, this means that in the usual cases (like my one) this file looks like libwcs 4 libwcs4 (= 4.8.1-1) right? 4.8.1-1 is the current version and the first to be packaged, so it should be safe to use this one. Then, I should install this in my installation rule in debian/rules [...] No. Please read dh_installdeb(1). From there, I would assume that I need to create a file debian/libwcs4.shlibs containing the line shlibs.libwcs4 Is this correct? Or do I not need to specify this since libwcs4.shlibs is a default name? I am also wondering why there are sometimes packages which dont have shlibs.* and *.shlibs files, but install shared libraries (popt as an example, or cfitsio3). Perhaps the manual should be updated to point to a simple package that does use shlibs still. It would be nice to add the interface to debhelper there. Then, the policy manual states that I have to put a a call to dpkg-shlibdeps into my debian/rules file, but to which rule do I have to add this? debhelper (dh_shlibdeps) does this for you already. OK. If I may suggest, I'd urge you to try your hands with something easier first. Library packaging is non-trivial, and requires great care, and often deeper knowledge of Debian. Hmm, my main motivation at the end is to put some astrophysical binaries and python packages (see my ITP list) to Debian, and for this I need to start with the very first dependency. And since I could clear up almost all lintian complaints, I would think that this is a good way, isn't it? Best regards Ole -- 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/ytzipoj1m0f@news.ole.ath.cx
Re: Shared libs dependencies
Gergely Nagy alger...@balabit.hu writes: Ole Streicher debian-de...@liska.ath.cx writes: libwcs 4 libwcs4 (= 4.8.1-1) debian/libwcs4.shlibs should be the line you wrote above. It would be good if the policy would use the same naming conventions as the debhelper. Currently, the Debian Policy states (8.6.4) | if you have multiple binary packages, you might want to call it | debian/shlibs.package instead ^^ while dh_installdeb(1) means | package.shlibs ^^ | These control files are installed into the DEBIAN directory. which was really confusing for me. rename your current shlibs.libwcs4 file to debian/libwcs4.shlibs, and debhelper will do the right thing, and install it. Thank you very much. Now I hope to get everything at the right place... I have the feeling, that lintian is quite lazy about shared libs; at least it does not complain about a missing shlibs file. Best regards Ole -- 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/ytzehz71k4n@news.ole.ath.cx
Re: Package separation/naming conventions
Jakub Wilk jw...@debian.org writes: * Ole Streicher debian-de...@liska.ath.cx, 2011-09-23, 13:58: My question is not the naming of the binary packages. The original library is called wcslib, and to maximize confusion, there exists somewhere else another (not compatible, less used) library for the same task, called libwcs, which is part of a wcstools package. To avoid naming confusion, I would like to name all packages wcslib; If you believe that shared library name is confusing, then convince upstream to change it. This is not an option: the wcslib exists under this name already for some years, and is always referenced under this name. Changing the name to libwcs would confuse people with the older libwcs library (which is incompatible). however lintian doesn't like my idea to call the shared library package wcslib4. Can/should I ignore this warning since I have a reason to do so? You can. You should not. :) What is the rationale behind this? The package name is (as far as I understand) for the user, and dependencies are resolved not on the package name, but on the soname (am I right here?). And for the user, it is important that this is the libwcs coming from the wcslib package and not the one coming from the wcstools package. Why not put that into the name? I found some other packages (namely zlib1g) where the package name does not match the soname. This is not a very good example. The Debian package name is like this for historical reasons. (And you don't change shared library package name without very good reasons, especially not when it has over 1900 reverse dependencies...) The same: isn't the dependency made of the soname and not of the package name? I thought this is just this debian/shlibs stuff about? At the end, naming them as I proposed (libwcs4, wcslib-dev, wcslib-doc, wcslib-util) would be OK for Debian? Best Ole -- 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/ytz39fn1h49@news.ole.ath.cx
Re: Package separation/naming conventions
Jakub Wilk jw...@debian.org writes: * Ole Streicher debian-de...@liska.ath.cx, 2011-09-21, 16:42: - libwcs4 and libwcs4-dev - libpgsbox4 and libpgsbox4-dev First of all, don't version your -dev package(s), unless you want to keep multiple versions of it in the archive at the same people. (You probably don't.) Also, unless there's good reason to separate -dev package, I'd create just a single one. So I would just create a common wcslib-dev package, correct? And, which dependencies should the wcslib-dev package have? libpgsbox.a would contain references to pgplot5; which is non-free, old and ugly. However, in most of the cases one would just develop for libwcs, so libpgsbox.a is just for some rare special cases. Should wcslib-dev therefore suggest pgplot, but not depend on it? Or is the link here made with the suggests/enhances dependency? And what would then suggest what? libwcs4-dev suggests wcslib-doc, or vice versa? You can use both. Or none. Users will find out which package they need anyway, so don't worry about it. :) How would they do that? I personally would find it quite confusing to find the development headers and documentation of libpgsbox4 in wcslib-devel resp. wcslib-doc. - libwcs4-tools (two small executable) - libpgsbox4-tools (one small executable) That make sense (except there's probably no need to version *-tools packages). To summarize: libwcs4 . shared library for libwcs.4.so libpgsbox4 .. shared library for libpgsbox.4.so --- depends on libwcs4, pgplot5 wcslib-dev .. headers and static libs for libwcs and libpgsbox --- recommends libwcs4, wcslib-doc --- suggests libpgsbox4, pgplot5 wcslib-doc .. API documentation of libwcs and libpgsbox --- suggests wcslib-dev libwcs-tools small tools built with libwcs4 --- depends on libwcs4 libpgsbox-tools . small tool built with libpgsbox --- depends on libwcs4, libpgsbox4, pgplot5 Any comments/improvements here? Is the division into main and contrib done automatically based on the dependencies to non-free packages? And if a package requires a non-free package to build, will it automatically go to contrib, even if the package itself (like libwcs4) has no dependency to non-free? Best regards Ole -- 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/ytz7h512exk@news.ole.ath.cx
Re: Package separation/naming conventions
Hi Ansgar, Ansgar Burchardt ans...@debian.org writes: Ole Streicher debian-de...@liska.ath.cx writes: Is the division into main and contrib done automatically based on the dependencies to non-free packages? No, it is done by hand using the Section field in debian/control. OK, so I have to add the flags there. If it has a contrib/non-free build-dependency, the source package needs to go to contrib as well. It cannot build binaries in main in that case. My problem here is: the source package contains libwcs which may be built (and used) completely without non-free dependencies, and libpgsbox which needs a non-free library to be built and used. Is there a way to get libwcs into main and libpgsbox into contrib? Can I specify build-dependencies separately for each binary package? Best Ole -- 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/ytz39fo3h85@news.ole.ath.cx
Re: Package separation/naming conventions
Jakub Wilk jw...@debian.org writes: A -dev package should have a strict versioned dependency on all the shared libraries it provides .so symlink for. This is clear, but means that the wcslib-dev would depend on libpgsbox4, and therefore on pgplot5, which is not nice. libpgsbox.a would contain references to pgplot5; which is non-free, old and ugly. Wait, you link *statically* to a non-free library? That'd make your binary package contain non-free bits, and as a consequence the whole source package would have to go to non-free. No; it is just that libpgsbox.a has symbols that are resolved in pgplot5. So, the library itself is not linked, but the user needs to link libpgplot.a when he wants to statically link libpsgbox.a; which means that the library itself is free but needs a non-free one. Also, now I notices that (at least according to your ITP), libwcs is licensed under the GPLv3+. We can't legally distribute GPLed software linked (statically or dynamically) to non-free stuff! I will contact the original author to clarify this. It seems that the easiest solution would be to remove the libpgsbox stuff completely unless someone really needs it. Best Ole -- 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/ytzy5xg1zpl@news.ole.ath.cx
Package separation/naming conventions
Dear list, I am currently packaging the wcslib package (Bug #641624) as my first Debian package, and I am wondering about the naming conventions. The package contains two libraries, some tools and an common API documentation for both libraries. I would now make the following binary packages: - libwcs4 and libwcs4-dev - libpgsbox4 and libpgsbox4-dev containing the shared libs resp. the static libs+headers of the two libraries - wcslib-tools containing the included binaries - wcslib-doc containing the documentation of the two libraries. First question is now, Is it wise to call a package containing documentation for libwcs4 wcslib-doc? Usually, the doc has the same base name as the according library, hasn't it? Or is the link here made with the suggests/enhances dependency? And what would then suggest what? libwcs4-dev suggests wcslib-doc, or vice versa? Second question: libpgsbox4 depends on a package that is in non-free (pgplot5), and one of the (three) programs that are in wcslib-tools depend on libpgsbox4. Should I divide wcslib-tools into two packages like the following? - libwcs4-tools (two small executable) - libpgsbox4-tools (one small executable) The three programs are useful by its own. Best regards Ole -- 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/ytzhb46q7n4@news.ole.ath.cx
