Re: Bug#503712: the gs-common problem
Cyril Brulebois (06/01/2009): > Thomas Viehmann (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! If someone else finds it strange to have the following wdiff between the version currently in testing and the one uploaded to t-p-u: “libcomerr2 (>= [-1.33-3),-] {+1.01),+}”, see e2fsprogs' “Add dpkg-gensymbols support to track ABI changes to the libraries” in 1.41.1-1 or “Add more historical information to the debian/*.symbol files” in 1.41.1-3. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#503712: the gs-common problem
Hello, Thomas Viehmann (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
Re: 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 Mon, 05 Jan 2009 23:33:33 +0100 + ghostscript (8.62.dfsg.1-3.2) unstable; urgency=low * Non-maintainer upload.
Re: Bug#503712: the gs-common problem
Luk Claes wrote: >> Thanks for looking into this! Uploaded ghostscript 8.62.dfsg.1-3.2. > unblocked Thanks! All the best for 2009. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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 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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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 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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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 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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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 Sun, 28 Dec 2008 11:18:18 +0100 + ghostscript (8.62.dfsg.1-3.1) unstable; urgency=medium * Non-maintainer upload.
Re: 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 <> 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 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
Re: 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 < 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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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 <
Re: 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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org