Offering the ghostscipt packages for addoption
Hi, recently i have started a new job and i have to work harder than expected and to travel a lot. So, i am not able to mantain my Debian packages in a satisfactory way, and the number of open bugs is growing... This is true in particular for the ghostscript (GS) packages. So, i am quite sorry, but i have to offer the following packages for addoption: - gs - gs-aladdin - gs-fonts - gs-fonts-other I would like to remark that ghostscript (the postscript interpreter and previewer by Alan P. Deutsch) is a very good piece of software, and that the upstream support is very good (see http://www.cs.wisc.edu/~ghost/index.html). Moreover, the maintenance of these packages is very stimulating: there are a lot of users that give interesting feedback and suggestions. The only problem is that gs-aladdin is not distributed under a DSFG-free licensei, so perhaps these packages are not OK for free software purists. (New versions of ghostscript are released under the aladdin license, that allows for free usage, but that restricts copying, distribution and modification. After one year, the new versions are re-distributed under GPL). Thank you, Marco Pistore -- Marco Pistore ITC-IRST phone: +39 0461 314 334 Via Sommarive 18 fax : +39 0461 314 591 38050 Povo (Trento), ITALYemail: [EMAIL PROTECTED]
Help needed with libpaperg_1.0.3-10
Hi, a pair of days ago i have uploaded a new version of libpaper and libpaperg (version 1.0.3-10), to close a release critical bug: in the preinst of libpaperg i have added two diversions, since both libpaper and libpaperg contain the files /usr/sbin/paperconfig and /usr/bin/paperconf. Unfortunately, something is not working and i have received three bug reports: there are problems when upgrading from libpaperg_1.0.3-9 to libpaperg_1.0.3-10: this is the more interesting (bug#23644): Package: libpaperg Version: 1.0.3-9 Preparing to replace libpaperg 1.0.3-9 (using libpaperg_1.0.3-10.deb) ... Adding `diversion of /usr/bin/paperconf to /usr/bin/paperconf.libc5 by libpaperg' Adding `diversion of /usr/sbin/paperconfig to /usr/sbin/paperconfig.libc5 by libpaperg' Unpacking replacement libpaperg ... dpkg: error processing libpaperg_1.0.3-10.deb (--unpack): trying to overwrite `/usr/bin/paperconf', which is the diverted version of `¼Z¨^ɸ×' (package:libpaperg) Errors were encountered while processing: libpaperg_1.0.3-10.deb E: Sub-process returned an error code Please notice the strange chars in the error message: i really do not know how this can be my fault! Moreover, I have tried to reproduce the bug, with no results: all works correctly on my machine. So, i really need your help with this bug: i am appending the preint script for libpaperg_1.0.3.10 (that introduces the diversions). Thank you, Marco libpaperg.preinst --- #! /bin/sh set -e FIRST_VERSION_WITH_DIVERT=1.0.3-10 if [ $1 = install ]; then dpkg-divert --package libpaperg --add --rename \ --divert /usr/bin/paperconf.libc5 /usr/bin/paperconf dpkg-divert --package libpaperg --add --rename \ --divert /usr/sbin/paperconfig.libc5 /usr/sbin/paperconfig fi if [ $1 = upgrade ] /usr/bin/dpkg --compare-versions $2 lt $FIRST_VERSION_WITH_DIVERT ; then dpkg-divert --package libpaperg --add \ --divert /usr/bin/paperconf.libc5 /usr/bin/paperconf dpkg-divert --package libpaperg --add \ --divert /usr/sbin/paperconfig.libc5 /usr/sbin/paperconfig fi exit 0 - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#22942: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
On 11 Jun 1998, Gregory S. Stark wrote: Marco Pistore [EMAIL PROTECTED] writes: Now, in hamm the binaries are only in libpaperg, since they are linked against libc6 libraries; package libpaper in hamm contains only the libraries. So, the original cause of the problem is that the binaries were in the library package. The policy specifically prohibits that precisely because of these problems. And you're proposing the libc6 versions keep doing the same thing that caused the problem in the first place. What I would suggest would be: libpaper: libc5 libraries only libpaperg: libc6 libraries only libpaper-utils: both binaries, depends on libpaper|libpaperg with wrapper scripts to choose the right ones somehow This will at least avoid the problem in the future, as another version of the library can be installed simultaneously without conflicting with the existing libraries. greg Yes, you are right. However, if i split the package now, some packages in hamm should then depend on libpaper-utils (rather than on libpaperg), and should be reuploaded. I do not think that it is convenient to do this change during a deep freeze. I'll split the package in slink. Thanks, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#22942: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
On 5 Jun 1998, Manoj Srivastava wrote: Hi, I think I'm failing to follow something basic here. Does paperconf depend on the libc6 shared libraries? If so, there is no way one could use the binaries without loading libpaperg, right? Secondly, Hamm is supoposed to be libc6. Hi, sorry for the delay in the answer: my machine went down during the week-end and i spent a lot of time to recover (and to re-subscribe to the mailing lists...) The problem is that, in bo, the package libpaper contained both the libraries and the binaries. There are bo packages that depend on libpaper and that use the libraries (this is the case, for instance, of gs) and other packages that depend on libpaper and use the binaries (this is the case, for instance, of debiandoc-sgml). Now, in hamm the binaries are only in libpaperg, since they are linked against libc6 libraries; package libpaper in hamm contains only the libraries. So, if an user replaces the bo libpaper package with the hamm libpaper package, package debiandoc-sgml stops to work, but their dependencies are satisfied (this can be solved, of course, by installing the hamm version of debiandoc-sgml). To avoid this, i have to assure that, when the hamm libpaper package is installed, also libpaperg is installed, so that the binaries are present on the system. This is why i hadded Depends: libpaperg in libpaper. Marco == Marco Pistore [EMAIL PROTECTED] writes: Marco The problem is that libpaper does not provide just the Marco library, but also a pair of executables (paperconf and Marco paperconfig). A package that depends on libpaper can use both Marco the library and the executables. libpaper contains this, or libpaperg? libpaper in bo, libpaperg in hamm... Marco When i had to provide both the libc5 and the libc6 version of the Marco package, i decided to put the binaries only in the libc6 (i.e., Marco libpaperg). The libc5 package (libpaper) should however depend on the Marco libc6 package, to assure that the packages depending on libpaper can use Marco the executables.[1] Which library do the executable depend on? I think this is about time we reduced continuing support for libc5 in Hamm, especially when a libc6 replacement is available. The executables depend only on libc6 libraries. Marco SOLUTION 3 Marco -- Marco Well, we can also decide that to leave the situation as it is. In this Marco way, however, users would not be able to install the new version of the Marco library without also installing libpaperg (and libc6...) The objection, for hamm, seems ridiculous to me. I mean, is libc6 not a release goal for Hamm? We are strenuously trying to save people from a release goal? What am I missing? BTW, I think Solution 3 is not really a solution. I think we should just get rid of libpaper. On my machine, no package actually depends on libpaper anyway; they all depend on libpaperg. libpaperg should just replace and conflict with libpaper, and no libpaper be provided in Hamm. In this way, it would not be possible to use some of the bo packages on hamm (more in general, hamm is supposed to provide also the libc5 version of the libraries, if they were already present in bo). So, i cannot simply get rid of libpaper. Another possible solution could be to make libpaper conflict with all the bo packages that use the binaries (there are only a pair of them). In this way, for instance, an user that installs the hamm verison of libpaper, is obliged to update also debiandoc-sgml... Thanks for your comments, Marco What am I missing? manoj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#22942: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
On Fri, 5 Jun 1998, Remco Blaakmeer wrote: On Fri, 5 Jun 1998, Marco Pistore wrote: SOLUTION 4 Let the programs be in both packages, but use dpkg's diversions to move away the libc5 binaries when libpaperg is installed and remove the diversions on remove of libpaperg. Only drawback: a little (?) waste of hard drive space. See 'dpkg-divert --help' for help. I couldn't find a man page for it. Ehi, this is a good idea! Thanks, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
Hi, thanks for your comments on this problems! I am sorry for the delay in the answer: there have been problems with the my mail server during the week-end... SUMMARY: the problem is that libpaper depends on libpaperg, which is bad, since it can create problems when upgrading from bo. The dependency is needed since some executables, that in bo were present in libpaper, are now in libpaperg, but the bo packages that use these executables just depend on libpaper. The following two solutions have been proposed, that seem to be particularly satisfactory: On Fri, 5 Jun 1998, Remco Blaakmeer wrote: SOLUTION 4 Let the programs be in both packages, but use dpkg's diversions to move away the libc5 binaries when libpaperg is installed and remove the diversions on remove of libpaperg. Only drawback: a little (?) waste of hard drive space. See 'dpkg-divert --help' for help. I couldn't find a man page for it. Otherwise, i could make libpaper conflict with the bo versions of the packages that depend on libpaper and use the executables (an example is debiandoc-sgml). In this way, the user is forced to install the hamm versions of these packages, that depend on libpaperg. Any comment in welcome. Thank you, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
Hi! Recently, Santiago opened a bug against libpaper. This is one of the RELEASE CRITICAL bugs, and we were not able to find a satisfactory solution. Hopefully, you have some useful suggestion... Here is the history: On Thu, 28 May 1998, Santiago Vila wrote: Subject: Bug#22942: libpaper depends on libpaperg I think there is not (or there should not be) anything in libpaper to make it to depend on libpaperg. I'm tagging this bug as important because the upgrade will be smoother having this bug fixed (users should be able to upgrade libraries from oldlibs before installing any other libc6 library). The problem is that libpaper does not provide just the library, but also a pair of executables (paperconf and paperconfig). A package that depends on libpaper can use both the library and the executables. When i had to provide both the libc5 and the libc6 version of the package, i decided to put the binaries only in the libc6 (i.e., libpaperg). The libc5 package (libpaper) should however depend on the libc6 package, to assure that the packages depending on libpaper can use the executables.[1] It is not possible to put the executables in both packages: the packages would conflict, and this is not good, since it can be required to have both the libc5 and the libc6 versions of a library installed. It is also not possible to put the executables in both packages AND to put in libpaperg a Replaces: libpaper (or vice-versa), since in this case it is possible to end with libpaper installed but without the executables (1- install libpaper; 2- install libpaperg; 3- remove libpaperg). The possible solutions are: SOLUTION 1 (Suggested by Wichert) - Create the packages: libpaper - the old libc5 library. May suggest libpaper-bin. libpaperg - the new libc6 library. May suggest libpaper-bin. libpaper-bin - the binariesmanpages. Depend on libpaperg Here the problems are that we do not guarantee, by installing libpaper, that the executables are present in the system. OTOH, by making libpaper depend on libpaper-bin, the installation of libpaper would also force the installation of libpaperg, which is what we wanted to avoid. Moreover, one on the executables (paperconfig) is used in the postinst of libpaper to configure the library; if the executables do not appear in the libpaper package, it is not possible to call paperconfig in the postinst, so a different way to initialize the library should be used (for instance, a subset of paperconfig should be included in the postinst). SOLUTION 2 -- Create the packages: - libpaper: man pages + binaries + libc5-libraries in /usr/lib/libc5-compat; does NOT depend on libpaperg - libpaperg : man pages + binaries + libc6-libraries; conflicts with libpaper - libpaper-oldlib : only the libc5-libraries in /usr/lib/libc5-compat; depends on libpaperg, conflicts with libpaper, provides libpaper When using only the libc5 libraries, it is sufficient to install the new version of libpaper; when you want to install also libpaperg, you have to replace libpaper with libpaper-oldlib. In this way, however, there would be two versions of the libc5 packages and the situation is not exactly clean. SOLUTION 3 -- Well, we can also decide that to leave the situation as it is. In this way, however, users would not be able to install the new version of the library without also installing libpaperg (and libc6...) Any comment and help is welcome! Thank you, Marco Pistore (libpaper maintainer) - [1] There is also another reason to make libpaper depend on libpaperg: these two packages share a config file. However, this file is not part of the package, but is created in the postinst and removed in the postrm, in case of purge. The config file should be removed only when both libpaper and libpaperg are purged, and this can be easily guaranteed in the postrm scripts. So, in my opinion, it should not be too difficult to solve _this_ problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
