Bug#503712: the gs-common problem
Hello, Thomas Viehmann t...@beamnet.de (06/01/2009): Please allow me the liberty of proposing the attached NMU for fixing #503712 (and opportunistically #510691 now that we know, but I've left all other dependency stuff out). If considered desirable, it would be nice if someone could sponsor this. Packages are available[1]. on its way, thanks again! Mraw, KiBi. signature.asc Description: Digital signature
Bug#503712: the gs-common problem
Hi,
Luk Claes wrote:
Thanks for looking into this! Uploaded ghostscript 8.62.dfsg.1-3.2.
unblocked
Please allow me the liberty of proposing the attached NMU for fixing
#503712 (and opportunistically #510691 now that we know, but I've left
all other dependency stuff out).
If considered desirable, it would be nice if someone could sponsor this.
Packages are available[1].
Kind regards
T.
1. http://vman.de/debian/
--
Thomas Viehmann, http://thomas.viehmann.net/
diff -u ghostscript-8.62.dfsg.1/debian/control ghostscript-8.62.dfsg.1/debian/control
--- ghostscript-8.62.dfsg.1/debian/control
+++ ghostscript-8.62.dfsg.1/debian/control
@@ -121,7 +121,7 @@
Package: libgs-dev
Section: libdevel
Architecture: any
-Depends: ${shlibs:Depends}, libgs8
+Depends: ${shlibs:Depends}, libgs8 (= ${binary:Version})
Conflicts: libgs-esp-dev ( 8.62)
Replaces: libgs-esp-dev ( 8.62)
Provides: libgs-esp-dev
diff -u ghostscript-8.62.dfsg.1/debian/changelog ghostscript-8.62.dfsg.1/debian/changelog
--- ghostscript-8.62.dfsg.1/debian/changelog
+++ ghostscript-8.62.dfsg.1/debian/changelog
@@ -1,3 +1,14 @@
+ghostscript (8.62.dfsg.1-3.2lenny0) testing; urgency=low
+
+ * Non-maintainer upload to testing, mainly to get fix
+from 8.62.dfsg.1-3.2:
+- Make ghostscript depend on gs-common to prevent removal.
+ Drop gs-common - ghostscript-x dependency to not force the
+ X version on all users. Hopefully Closes: #503712.
+ * libgs-dev: version Depends: libgs8. Closes: #510691.
+
+ -- Thomas Viehmann t...@beamnet.de Mon, 05 Jan 2009 23:33:33 +0100
+
ghostscript (8.62.dfsg.1-3.2) unstable; urgency=low
* Non-maintainer upload.
Bug#503712: the gs-common problem
Thomas Viehmann wrote: Adeodato Simó wrote: * Thomas Viehmann [Sun, 28 Dec 2008 21:10:36 +0100]: As promised on IRC, the only way to end the madness of my mails on the subject is to either say no, no dependency funnies, we want .config hacks or fixing dependencies is better than .config hacks, or something entirely different 22:04 dato tomv_w: if both options work, I also lean towards the dependency on gs-common Thanks for looking into this! Uploaded ghostscript 8.62.dfsg.1-3.2. unblocked Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
* Thomas Viehmann [Sun, 28 Dec 2008 21:10:36 +0100]: As promised on IRC, the only way to end the madness of my mails on the subject is to either say no, no dependency funnies, we want .config hacks or fixing dependencies is better than .config hacks, or something entirely different 22:04 dato tomv_w: if both options work, I also lean towards the dependency on gs-common -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org When all is summed up, a man never speaks of himself without loss; his accusations of himself are always believed; his praises never. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Adeodato Simó wrote: * Thomas Viehmann [Sun, 28 Dec 2008 21:10:36 +0100]: As promised on IRC, the only way to end the madness of my mails on the subject is to either say no, no dependency funnies, we want .config hacks or fixing dependencies is better than .config hacks, or something entirely different 22:04 dato tomv_w: if both options work, I also lean towards the dependency on gs-common Thanks for looking into this! Uploaded ghostscript 8.62.dfsg.1-3.2. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
For the latter, it would be cool if the maintainers of the affected packages, Vincent for latex-make Sylvain and David for page-crunch the Zope guys and Andreas and Fabio for zope-textindexng3 could weigh in here. I'll look at your packages, but if you already know whether it works without ghostscript-x or not, it'd be great if you could give me a shout. page-crunch depends on gs-common for 'pdf2ps' and 'ps2pdf'. From what I understand we can replace 'gs-common' with 'ghostscript'. Do you want to sponsor a new package release? -- Sylvain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Hi Sylvain, thanks for your comments! Sylvain Beucler wrote: For the latter, it would be cool if the maintainers of the affected packages, Vincent for latex-make Sylvain and David for page-crunch the Zope guys and Andreas and Fabio for zope-textindexng3 could weigh in here. I'll look at your packages, but if you already know whether it works without ghostscript-x or not, it'd be great if you could give me a shout. page-crunch depends on gs-common for 'pdf2ps' and 'ps2pdf'. From what I understand we can replace 'gs-common' with 'ghostscript'. Do you want to sponsor a new package release? Thanks for offering to prepare an update. The idea is to not change reverse dependencies at this point but to reduce gs-common to only include ghostscript and not ghostscript-x, so your package would be fine depending on gs-common. All the best for the new year. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Thomas Viehmann wrote:
So this is how an NMU choosing the include hack in .config route would
look like.
I'm not quite convinced that this is actually better than having
ghosscript depend on gs-common, gs-common not depend on ghostscript-x
and checking the reverse (build-)depends for breakage.
So build logs for (all but the one contrib) reverse build depends are
at[1]. All seem to succeed, two seem to build-depend indirectly
ghostscript-x (via transfig via gs-gpl, latex-mk via transfig).
I'll check the debs somewhat, too, but if we think that ghostscript
depending on gs-common and living with the circular depends solves the
problem, this might be a more conservative way to fix this for lenny.
Two maintainers of reverse dependencies have replied already that their
packages don't need ghostscript-x, leaving one with some breakage potential.
Given that there are two possible vectors with more-or-less
ready-to-upload packages, we should want to decide this soonish.
I'm leaning towards the dependency change a bit. Note that ghostscript
seems to be the only package conflicting with gs-common.
Kind regards
T.
1.
http://people.debian.org/~tviehmann/building-with-gs-common-not-depending-on-ghostscript-x/
--
Thomas Viehmann, http://thomas.viehmann.net/
diff -u ghostscript-8.62.dfsg.1/debian/control ghostscript-8.62.dfsg.1/debian/control
--- ghostscript-8.62.dfsg.1/debian/control
+++ ghostscript-8.62.dfsg.1/debian/control
@@ -10,10 +10,10 @@
Architecture: any
Conflicts: gs ( 8.62), gs-esp ( 8.62), gs-gpl ( 8.62), gs-afpl ( 8.62), gs-aladdin ( 8.62), gs-cjk-resource ( 1.20010910-1), gs-pdfencrypt ( 7.00), gs-common ( 8.62)
Replaces: gs ( 8.62), gs-esp ( 8.62), gs-gpl ( 8.62), gs-afpl ( 8.62), gs-aladdin ( 8.62), gs-pdfencrypt ( 7.00), gs-common ( 8.62)
-Provides: gs-pdfencrypt, postscript-viewer, gs-common
+Provides: gs-pdfencrypt, postscript-viewer
Recommends: psfontmgr
Suggests: ghostscript-x, hpijs
-Depends: ${shlibs:Depends}, gsfonts (= 6.0-1), defoma, debconf | debconf-2.0, debianutils (= 1.6), libgs8 (= ${binary:Version})
+Depends: ${shlibs:Depends}, gs-common (= 8.62.dfsg.1-3.2b), gsfonts (= 6.0-1), defoma, debconf | debconf-2.0, debianutils (= 1.6), libgs8 (= ${binary:Version})
Description: The GPL Ghostscript PostScript/PDF interpreter
Ghostscript is used for PostScript/PDF preview and printing. Usually as
a back-end to a program such as ghostview, it can display PostScript and PDF
@@ -65,12 +65,11 @@
Package: gs-common
Architecture: all
-Priority: extra
-Depends: ghostscript, ghostscript-x
-Description: Transitional package
+Priority: optional
+Depends: ghostscript
+Description: Dummy package depending on ghostscript
This dummy package is provided for a smooth transition from the
previous gs-.../gs-common combo (the packages are replaced by ghostscript).
- It may safely be removed after installation.
Package: ghostscript-x
Architecture: any
diff -u ghostscript-8.62.dfsg.1/debian/changelog ghostscript-8.62.dfsg.1/debian/changelog
--- ghostscript-8.62.dfsg.1/debian/changelog
+++ ghostscript-8.62.dfsg.1/debian/changelog
@@ -1,3 +1,12 @@
+ghostscript (8.62.dfsg.1-3.2b) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Make ghostscript depend on gs-common to prevent removal.
+Drop gs-common - ghostscript-x dependency to not force the
+X version on all users.
+
+ -- Thomas Viehmann t...@beamnet.de Sun, 28 Dec 2008 11:18:18 +0100
+
ghostscript (8.62.dfsg.1-3.1) unstable; urgency=medium
* Non-maintainer upload.
Bug#503712: the gs-common problem
As promised on IRC, the only way to end the madness of my mails on the subject is to either say no, no dependency funnies, we want .config hacks or fixing dependencies is better than .config hacks, or something entirely different, so here is some more data: Thomas Viehmann wrote: I'll check the debs somewhat, too, but if we think that ghostscript depending on gs-common and living with the circular depends solves the problem, this might be a more conservative way to fix this for lenny. Using debdiff, the only file differences (aside from a few shlibs bumps, ordering, and minor size differences, the control fields matched up) are - one pdf in one package (geda-symbols) changed the paper format and then dropped below the compression threshold (building in a chroot?), - the doc package of log4c had a couple of more symlinked manpages, apparently due to changes in the manpage generating tex file. So IMO dropping ghostscript-x from gs-common build-deps looks reasonably safe as in not changing anything rebuild-wise. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Hi, Thomas Viehmann wrote: Niko Tyni wrote: Maybe configure script is badly worded: It's most blatant abuse, but I'd just stick it into a /var/lib/dpkg/info/ghostscript.config unless there are apt-get-lookalikes that don't call that at the beginning of an upgrade. If the user produces the bad situation with dpkg by himself, well, who cares. I see. It's blatant abuse indeed, but it might work. The preconfiguration only happens if debconf and apt-utils are installed (see /etc/apt/apt.conf.d/70debconf and /usr/sbin/dpkg-preconfigure), but according to popcon more than 99.8% of all installations have them. If this is the chosen approach, the script could as well fix the etch gs-common.prerm script instead of removing it; I think something like if md5sum --status --check EOF 1959479be1e513d94a22f6fad8227fa3 /var/lib/dpkg/info/gs-common.prerm EOF then sed -i 's/defoma-app -t \(purge\|clean\) gs$/ || true/' \ /var/lib/dpkg/info/gs-common.prerm || true fi should do. So this is how an NMU choosing the include hack in .config route would look like. I'm not quite convinced that this is actually better than having ghosscript depend on gs-common, gs-common not depend on ghostscript-x and checking the reverse (build-)depends for breakage. I might investigate that option in some more detail, too, but now we have an NMU option from the gross hack that works for many situations department. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ diff -u ghostscript-8.62.dfsg.1/debian/changelog ghostscript-8.62.dfsg.1/debian/changelog --- ghostscript-8.62.dfsg.1/debian/changelog +++ ghostscript-8.62.dfsg.1/debian/changelog @@ -1,3 +1,14 @@ +ghostscript (8.62.dfsg.1-3.2) unstable; urgency=low + + * Non-maintainer upload. + * Gross hack: Add debian/ghostscript.config that attempts to fix +(etch) gs-common.prerm. This also necessitates the (otherwise +useless) ghostscript.templates. +Original idea from apache2-apache2.2, +details by Niko Tyni, bugs my own. Closes: #503712 + + -- Thomas Viehmann t...@beamnet.de Sat, 27 Dec 2008 20:58:00 +0100 + ghostscript (8.62.dfsg.1-3.1) unstable; urgency=medium * Non-maintainer upload. only in patch2: unchanged: --- ghostscript-8.62.dfsg.1.orig/debian/ghostscript.templates +++ ghostscript-8.62.dfsg.1/debian/ghostscript.templates @@ -0,0 +1,5 @@ +Template: ghostscript/dummy +Type: text +Description: Dummy template + to facilitate hack in ghostscript.config. + only in patch2: unchanged: --- ghostscript-8.62.dfsg.1.orig/debian/ghostscript.config +++ ghostscript-8.62.dfsg.1/debian/ghostscript.config @@ -0,0 +1,13 @@ +#!/bin/sh + +set -e + +# This is one gross hack, do not imitate. See bug #503712 for details. + +md5sum=$(md5sum /var/lib/dpkg/info/gs-common.prerm 2/dev/null | cut -f1 -d' ' || true ) +case $md5sum in +1959479be1e513d94a22f6fad8227fa3|7246294e40219cc849738edf49c1c852|0a6bfb6322d636faf08752d6427150c2) +sed -i 's/defoma-app -t \(purge\|clean\) gs$/ || true/' \ + /var/lib/dpkg/info/gs-common.prerm || true +;; +esac
Bug#503712: the gs-common problem
On Tue, 23 Dec 2008, Thomas Viehmann wrote: Niko Tyni wrote: On Tue, Dec 23, 2008 at 02:15:22PM +0100, Thomas Viehmann wrote: immediately after I sent the last mail, Sune Vuorela pointed me to apache2's fix for #390823: They simply remove the problematic maintainer script. The question then is where to do this in so it is reliably done before stuff happens. In one of the perl packages (because the upgrade of perl triggers this) is probably too ugly, maybe the configure script of ghostscript? I think it's too late to do it inside ghostscript, it would have to go in perl-modules. Maybe configure script is badly worded: It's most blatant abuse, but I'd just stick it into a /var/lib/dpkg/info/ghostscript.config unless there are apt-get-lookalikes that don't call that at the beginning of an upgrade. If the user produces the bad situation with dpkg by himself, well, who cares. I think this is the best strategy. Better to hack related packages. An alternative is to to add gs-common being added to apt's 01autoremove, but I think that the /var/lib/dpkg/info/ghostscript.config change is a better choice; it limits the number of source packages affected. I left some more notes on the bug, but this is the crux of it. -- Asheesh. -- You never know how many friends you have until you rent a house on the beach. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
On Tue, Dec 23, 2008 at 09:39:20PM +0100, Thomas Viehmann wrote: Niko Tyni wrote: On Tue, Dec 23, 2008 at 02:15:22PM +0100, Thomas Viehmann wrote: immediately after I sent the last mail, Sune Vuorela pointed me to apache2's fix for #390823: They simply remove the problematic maintainer script. I think it's too late to do it inside ghostscript, it would have to go in perl-modules. Maybe configure script is badly worded: It's most blatant abuse, but I'd just stick it into a /var/lib/dpkg/info/ghostscript.config unless there are apt-get-lookalikes that don't call that at the beginning of an upgrade. If the user produces the bad situation with dpkg by himself, well, who cares. I see. It's blatant abuse indeed, but it might work. The preconfiguration only happens if debconf and apt-utils are installed (see /etc/apt/apt.conf.d/70debconf and /usr/sbin/dpkg-preconfigure), but according to popcon more than 99.8% of all installations have them. If this is the chosen approach, the script could as well fix the etch gs-common.prerm script instead of removing it; I think something like if md5sum --status --check EOF 1959479be1e513d94a22f6fad8227fa3 /var/lib/dpkg/info/gs-common.prerm EOF then sed -i 's/defoma-app -t \(purge\|clean\) gs$/ || true/' \ /var/lib/dpkg/info/gs-common.prerm || true fi should do. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Hi, Niko Tyni wrote: Maybe configure script is badly worded: It's most blatant abuse, but I'd just stick it into a /var/lib/dpkg/info/ghostscript.config unless there are apt-get-lookalikes that don't call that at the beginning of an upgrade. If the user produces the bad situation with dpkg by himself, well, who cares. I see. It's blatant abuse indeed, but it might work. The preconfiguration only happens if debconf and apt-utils are installed (see /etc/apt/apt.conf.d/70debconf and /usr/sbin/dpkg-preconfigure), but according to popcon more than 99.8% of all installations have them. If this is the chosen approach, the script could as well fix the etch gs-common.prerm script instead of removing it; I think something like if md5sum --status --check EOF 1959479be1e513d94a22f6fad8227fa3 /var/lib/dpkg/info/gs-common.prerm EOF then sed -i 's/defoma-app -t \(purge\|clean\) gs$/ || true/' \ /var/lib/dpkg/info/gs-common.prerm || true fi should do. Barring objections, I'll test things and NMU along the lines Niko indicated on Sunday. Thanks to everyone for weighing in on the bug report. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Hi everyone, you have been involved in #503712 so it's been a while since the last activity here. contrary to Niko's last mail I propose to live with a circular dependency and - make ghostscript depend on gs-common ( -3.2 to be uploaded) - make gs-common NOT depend on ghostscript-x unless there is a compelling reason not to (i.e. massive breakage would a reason, that gs-common then will have to stay installed for lenny is not, the circular dependency in itself isn't, but if it causes problems...). IMO a single excess package is not that bad compared to requiring attention during an upgrade. I will check whether this is a problem for the reverse build-dependencies and dependencies. For the latter, it would be cool if the maintainers of the affected packages, Vincent for latex-make Sylvain and David for page-crunch the Zope guys and Andreas and Fabio for zope-textindexng3 could weigh in here. I'll look at your packages, but if you already know whether it works without ghostscript-x or not, it'd be great if you could give me a shout. Happy holidays and kind regards T. P.S.: When you reply, you might want to drop part of the CC madness. :) -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Hi again, immediately after I sent the last mail, Sune Vuorela pointed me to apache2's fix for #390823: They simply remove the problematic maintainer script. The question then is where to do this in so it is reliably done before stuff happens. In one of the perl packages (because the upgrade of perl triggers this) is probably too ugly, maybe the configure script of ghostscript? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Hi, I'm the maintainer of latex-make. Thomas Viehmann wrote: I will check whether this is a problem for the reverse build-dependencies and dependencies. For the latter, it would be cool if the maintainers of the affected packages, Vincent for latex-make Sylvain and David for page-crunch the Zope guys and Andreas and Fabio for zope-textindexng3 could weigh in here. I'll look at your packages, but if you already know whether it works without ghostscript-x or not, it'd be great if you could give me a shout. latex-make does not need the x driver (only ps2pdf in fact) (at runtime and at buildtime). So no problem for me to remove the gs-common - ghostscript-x dependency. In fact, I just see that I do not have gs-common installed on my system (whereas I heavily use latex-make). The 'provides: gs-common' from the 'ghostscript' package is enough. In my next upload, I will change gs-common to ghostscript (but, unless someone told me the contrary, I do not think it is needed for lenny) Happy holidays Vincent Happy holidays and kind regards T. P.S.: When you reply, you might want to drop part of the CC madness. :) -- Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble Téléphone: +33 4 76 61 20 11ENSIMAG - antenne de Montbonnot Fax:+33 4 76 61 20 99ZIRST 51, avenue Jean Kuntzmann Email: vincent.danj...@imag.fr 38330 Montbonnot Saint Martin -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
On Tue, Dec 23, 2008 at 02:15:22PM +0100, Thomas Viehmann wrote: immediately after I sent the last mail, Sune Vuorela pointed me to apache2's fix for #390823: They simply remove the problematic maintainer script. The question then is where to do this in so it is reliably done before stuff happens. In one of the perl packages (because the upgrade of perl triggers this) is probably too ugly, maybe the configure script of ghostscript? I think it's too late to do it inside ghostscript, it would have to go in perl-modules. Not sure if the case where perl-base is upgraded first and perl-modules lacks behind is just theoretical, but it would create the same effect. It would mean we'd need the hack in perl-base too. I'm obviously not thrilled by this ugliness, but it's doable. Thomas, thanks for driving this. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
Niko Tyni wrote: On Tue, Dec 23, 2008 at 02:15:22PM +0100, Thomas Viehmann wrote: immediately after I sent the last mail, Sune Vuorela pointed me to apache2's fix for #390823: They simply remove the problematic maintainer script. The question then is where to do this in so it is reliably done before stuff happens. In one of the perl packages (because the upgrade of perl triggers this) is probably too ugly, maybe the configure script of ghostscript? I think it's too late to do it inside ghostscript, it would have to go in perl-modules. Maybe configure script is badly worded: It's most blatant abuse, but I'd just stick it into a /var/lib/dpkg/info/ghostscript.config unless there are apt-get-lookalikes that don't call that at the beginning of an upgrade. If the user produces the bad situation with dpkg by himself, well, who cares. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
