Re: 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
Re: Bug#503712: the gs-common problem
Cyril Brulebois k...@debian.org (06/01/2009):
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!
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
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.
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 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-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 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-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 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-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 t...@beamnet.de 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
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
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 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-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 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-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
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
