Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 package ghostscript tags 528386 pending thanks Hi Till, On Sun, May 24, 2009 at 08:44:43PM +0200, Till Kamppeter wrote: - Splitted off the CUPS-related files into its own package, so that the requirements of cups and cups-client for the automatic update of the PPDs of existing print queues do not apply to the ghostscript core package. Added cups and cups-client to the Depends: entry of the new ghostscript-cups package, so that the automatic updates of the PPDs also works on updates to a new release of the distribution and not only on single-package updates. Added also perl as dependency to the ghostscript-cups package as it is also needed for the automatic PPD updates. A packaging release including above is now being built for Debian experimental, with the following exceptions regarding the newly added ghostscript-cups package: * does not conflict with older cups: Unneeded for any cups release part of an official Debian distribution release. If the need is Ubuntu-specific, then please add such quirks locally to Ubuntu fork of the package. * replaces older ghostscript, to ease upgrades due to contents overlap * recommends (not depends on) cups and cups-client, to avoid circular depends * improved indentation in postinst script * long description does not include historic notes * changelog entry shortened, and bug-closures added. Please elaborate on those changes if you feel that I overlooked or misunderstood something, or if you in other ways disagree with my judgement. As soon as the ghostscript package currently in unstable, 8.64~dfsg-7, has entered testing, I will rerelease these changes for unstable (possibly including any changes regarding above that you might suggest). Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkou0yIACgkQn7DbMsAkQLhZVgCeOrDRnOmIPfo7z1BjMUX59Kmh P5cAnR0iGnbocATKg7mHAjY/MbP0t9eF =DAya -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
Jonas Smedegaard [2009-05-25 0:11 +0200]: My comment was more general, however: Instead of developing on the Ubuntu package and then backport the changes to Debian, I recommend doing it the other way around: Join our team, apply changes to the Debian package, and pull the result to Ubuntu. If interested, and if you are not a Debian developer or have an Alioth account for other reasons, I would be quite happy to help you gain write access to our Git repository, so you can work directly on it. For the record, that's exactly how cups is maintained nowadays: Till has commit access to the Debian packaging bzr tree on alioth and we check that all the changes that get applied there make sense for Debian and Ubuntu. There are a few parts where cups behaves differently in Ubuntu, which we solved by asking lsb_release in debian/rules. We can do this for the ghostscript-cups dependency as well, but I agree that doing that package split would make sense in Debian, too. But it's not blocking anything. Till has collected experience with Debian packaging for several years now, and knows his way through patch systems, maintainer scripts, control files, etc. He is also _the_ upstream printing guru, so setting up a shared maintenance of the ghostscript package would totally make sense to me as well. It helped a lot to do so in cups, both distros benefit from fixes immediately and we don't maintain two packages. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
Jonas Smedegaard wrote: perl-base is sufficient if no modules are loaded, which is the case for the postinst routines. Perl-base is part of base so need not be declared as a dependency (except for versioned dependencies). You are right that defoma should care for its own dependencies. All in all: Please drop that perl dependency. Will do in Ubuntu's SpliX and Ghostscript, and only add cups and cups-client to the other driver packages. In all these cases we have only the simple perl -p -i -e ... calls in postinst, no applications written in Perl. The Debian package has evolved, but above changes are pretty simple, so I can easily reimplement using the new packaging structure of 8.64-4. I hesitate doing it right now, however: this change is a new feature, not a bugfix, and adding new binary packages has a risk of delaying acceptance into Debian. Who has to accept it? Masayuki Hatta, the Ghostscript maintainer? Or also other people? Is unstable in a release freeze currently? I would therefore prefer to finalize the other changes currently released in experimental (I just released -4 a moment ago), and _after_ that implement this last change. OK. What I want fixed for the package to enter unstable is this: a) symbols handling b) reduce linking c) coordination with dependent packages All three are related: Library symbols are supposed to be stable, but changes to compile flags change symbols, and recent changes even made some symbols disappear that was declared earlier on (libcairo was enabled for a short time, and at least on arm and i386 it offered some symbols that are now gone). I suspect that some symbols should not even be public, but do not understand library linking that well, so I might be completely off track here... The libcairo use in Ghostscript (Cairo output device) was dropped as it made the Ghostscript core pulling X and exactly for that the X output devices got modularized into ghostscript-x. The Cairo output device can only get reintroduced in the distro packages if it also gets modularized like the X devices. I have cleaned up and added symbols since release of Lenny. But for some reason they are not used during install (probably some ordering issue between debhelper, CDBS and d-shlibdeps). the linking routine warns about excess linking. I do not know if fixing that affects symbols or not. When symbols are working properly to track changes at each release, we can contact package maintainers that link against ghostscript and coordinate with them to verify that nothing breaks linking against our cleaned up release. This seems to be only cups, foomatic-filters and libspectre, but I have checked only binary dependencies using aptitude, do not know how to look up source dependencies). foomatic-filters links only against documented symbols of the Ghostscript API. So it cannot break on the disappearing of stray symbols like from Cairo. Which parts of CUPS link against Ghostscript? AFAIK the CUPS filters call Ghostscript via the command line. As you might notice from above, I really am fumbling here - I am not a C library expert. So any help would be much appreciated. Oh, a related thing: I included a static library, as I believe is required by Debian Policy. But I suspect it is not compiled correctly: All code is currently compiled with -cPIC and if I recall correctly static library needs to be compiled _without_ -fPIC. Upstream build routines seem to handle -fPIC correctly - except for the X11 driver, which fails to build using --shared if -fPIC is not explicitly added to CFLAGS (causing it to be added twice in many places). So if I am right that static lib needs to not use -fPIC then the package needs to either a) patch ghostscript build routines related to X11 driver, or b) compile everything twice - once as now, and another without --shared or -fPIC. In addition to these, there is also a simpler task: check with various bugreports if the issues are solved with the experimental package, and test if it works properly at all. Especially the second and the last change are necessarily needed in Debian, to avoid that the CUPS packages have to be different in Debian and Ubuntu. I do not consider Ubuntu upstream to Debian. It makes much better sense to me to do coordinated work together on the Debian package. Me not, too. I suggest to overtake these changes into Debian, once to make it possible that the CUPS package can stay synced (be the same in both Debian and Ubuntu), and second, as the CUPS package in Debian is switched to the PDF printing workflow (http://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format), to fix bugs in Ghostscript which cause problems in the PDF printing workflow, mainly bugs in PDF - PostScript conversion. Yes, I am looking forward to that switch. The switch is already there, the problems were that PDF - PostScript
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Mon, May 25, 2009 at 09:01:42AM +0200, Till Kamppeter wrote: Jonas Smedegaard wrote: The Debian package has evolved, but above changes are pretty simple, so I can easily reimplement using the new packaging structure of 8.64-4. I hesitate doing it right now, however: this change is a new feature, not a bugfix, and adding new binary packages has a risk of delaying acceptance into Debian. Who has to accept it? Masayuki Hatta, the Ghostscript maintainer? Or also other people? By Debian social norms, Masayuki Hatta has to accept it. He is a quiet guy, however, and these mails are cc'ed the package, reaching all team members. So I would say that the lack of response, keyed with earlier approval of moving to Git in the collab-maint group, can be interpreted as implicit approval. So please, let's move on :-) Is unstable in a release freeze currently? Nope. But the term unstable in Debian unstable refer to the distro, not each package, and library changes should be treated with care at all times (something I have learned the hard and embarrasing way with libgd and uw-imap). What I want fixed for the package to enter unstable is this: a) symbols handling b) reduce linking c) coordination with dependent packages All three are related: Library symbols are supposed to be stable, but changes to compile flags change symbols, and recent changes even made some symbols disappear that was declared earlier on (libcairo was enabled for a short time, and at least on arm and i386 it offered some symbols that are now gone). I suspect that some symbols should not even be public, but do not understand library linking that well, so I might be completely off track here... The libcairo use in Ghostscript (Cairo output device) was dropped as it made the Ghostscript core pulling X and exactly for that the X output devices got modularized into ghostscript-x. The Cairo output device can only get reintroduced in the distro packages if it also gets modularized like the X devices. Yes, I understood that from changelog entries. Thanks for confirming. My point above is that packages have been released that contained those symbols related to libcairo linkage, and in principle there is now a risk of other packages relying on those symbols and thus need rebuilding and/or patches. the libcairo symbols was one example - other symbols have disappeared too since the release of Lenny (I have not kept symbols earlier than that). Also, concretely for the libcairo linkage, we should perhaps reconsider if pulling in X11 libraries is still evil: With the improved X11 packaging it might no longer be too much of a burden. The libgd package has similarly been provided both with and without X11 linkage to optionally avoid bloat, but I expect to drop that now, as the bloat is no longer as large as a few years ago. When symbols are working properly to track changes at each release, we can contact package maintainers that link against ghostscript and coordinate with them to verify that nothing breaks linking against our cleaned up release. This seems to be only cups, foomatic-filters and libspectre, but I have checked only binary dependencies using aptitude, do not know how to look up source dependencies). foomatic-filters links only against documented symbols of the Ghostscript API. So it cannot break on the disappearing of stray symbols like from Cairo. Which parts of CUPS link against Ghostscript? AFAIK the CUPS filters call Ghostscript via the command line. Right. Checking only binary dependencies as I did can cause false positives like that. But the potential list is longer: there's a bunch of packages depending only on ghostscript-x even if at least one of them () is known to link against libgs8. Especially the second and the last change are necessarily needed in Debian, to avoid that the CUPS packages have to be different in Debian and Ubuntu. I do not consider Ubuntu upstream to Debian. It makes much better sense to me to do coordinated work together on the Debian package. Me not, too. I suggest to overtake these changes into Debian, once to make it possible that the CUPS package can stay synced (be the same in both Debian and Ubuntu), and second, as the CUPS package in Debian is switched to the PDF printing workflow (http://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format), to fix bugs in Ghostscript which cause problems in the PDF printing workflow, mainly bugs in PDF - PostScript conversion. Yes, I am looking forward to that switch. The switch is already there, the problems were that PDF - PostScript conversions blew up the print job files to unreasonable sizes. The needed fixes you have already added to your current Ghostscript package. The ghostscript-cups split is for another feature, the automatic update of
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
Jonas Smedegaard wrote: By Debian social norms, Masayuki Hatta has to accept it. He is a quiet guy, however, and these mails are cc'ed the package, reaching all team members. So I would say that the lack of response, keyed with earlier approval of moving to Git in the collab-maint group, can be interpreted as implicit approval. So please, let's move on :-) OK. Is unstable in a release freeze currently? Nope. But the term unstable in Debian unstable refer to the distro, not each package, and library changes should be treated with care at all times (something I have learned the hard and embarrasing way with libgd and uw-imap). The split is not a library change. the binary packages libgs8 and libgs-dev do not change by this step. The only changes in the libraries are all the cherry-picked bug fixes, but none of them changes the API. They only improve the stability and the correctness of the output. Yes, I understood that from changelog entries. Thanks for confirming. My point above is that packages have been released that contained those symbols related to libcairo linkage, and in principle there is now a risk of other packages relying on those symbols and thus need rebuilding and/or patches. the libcairo symbols was one example - other symbols have disappeared too since the release of Lenny (I have not kept symbols earlier than that). Also, concretely for the libcairo linkage, we should perhaps reconsider if pulling in X11 libraries is still evil: With the improved X11 packaging it might no longer be too much of a burden. To avoid pulling X11 is important for using head-less servers as print servers. They need to run Ghostscript but one wants to avoid installing X libraries only to satisfy Ghostscript's dependencies. The libgd package has similarly been provided both with and without X11 linkage to optionally avoid bloat, but I expect to drop that now, as the bloat is no longer as large as a few years ago. As the X itself is already split, I would like to leave it this way. The Cairo interface is still experimental AFAIK. So before doing changes here I would like to know if the Cairo interface is already considered stable. Right. Checking only binary dependencies as I did can cause false positives like that. But the potential list is longer: there's a bunch of packages depending only on ghostscript-x even if at least one of them () is known to link against libgs8. Can you tell which packages? Excellent. I notice now that you are also member of collab-maint, so you already have write access to the ghostscript Git :-D git clone ssh://till-gu...@git.debian.org/git/collab-maint/ghostscript Feel free to commit changes directly there. Except for adding new binary packages - please postpone such changes until after we've released to unstable. Oh, and if you are unfamiliar with some of the advanced CDBS features then try read the README.source file and if still puzzled (e.g. about the content of control.in and rules files) then please ask. OK. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
Please merge the following Ubuntu package version of Ghostscript into Debian: 8.64.dfsg.1-0ubuntu11 It has the following fixes and new feature (in addition to the ones of 0ubuntu9 and earlier): - pstoraster did not work when called with an input file name as the 6th command line argument. - The ps2write output device produces PostScript which is not DSC-conforming, so do not advertize it as DSC-conforming with a %!PS-Adobe-... magic string. Use %! instead. Otherwise the pstops CUPS filter cannot handle this output (https://bugs.launchpad.net/bugs/377011). - Fixed recognition of page size via /cupsPageSizeName in the cups output device. All page sizes were considered custom sizes if /cupsPageSizeName was not set. - Splitted off the CUPS-related files into its own package, so that the requirements of cups and cups-client for the automatic update of the PPDs of existing print queues do not apply to the ghostscript core package. Added cups and cups-client to the Depends: entry of the new ghostscript-cups package, so that the automatic updates of the PPDs also works on updates to a new release of the distribution and not only on single-package updates. Added also perl as dependency to the ghostscript-cups package as it is also needed for the automatic PPD updates. Especially the second and the last change are necessarily needed in Debian, to avoid that the CUPS packages have to be different in Debian and Ubuntu. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hi Till and others, On Sun, May 24, 2009 at 08:44:43PM +0200, Till Kamppeter wrote: Please merge the following Ubuntu package version of Ghostscript into Debian: - pstoraster did not work when called with an input file name as the 6th command line argument. - The ps2write output device produces PostScript which is not DSC-conforming, so do not advertize it as DSC-conforming with a %!PS-Adobe-... magic string. Use %! instead. Otherwise the pstops CUPS filter cannot handle this output (https://bugs.launchpad.net/bugs/377011). - Fixed recognition of page size via /cupsPageSizeName in the cups output device. All page sizes were considered custom sizes if /cupsPageSizeName was not set. Above is in Git already (cherry-picked from upstream yesterday). - Splitted off the CUPS-related files into its own package, so that the requirements of cups and cups-client for the automatic update of the PPDs of existing print queues do not apply to the ghostscript core package. Added cups and cups-client to the Depends: entry of the new ghostscript-cups package, so that the automatic updates of the PPDs also works on updates to a new release of the distribution and not only on single-package updates. Added also perl as dependency to the ghostscript-cups package as it is also needed for the automatic PPD updates. Sounds interesting. Is the perl dependency for the defoma code currently in ghostscript postinst? I haven't look closely at it, but is perl-base not sufficient? Could you please post a diff of this one change isolated - preferrably against the packaging work in Git? Or even better just applied directly to our Git here: git://git.debian.org/git/collab-maint/ghostscript.git. Especially the second and the last change are necessarily needed in Debian, to avoid that the CUPS packages have to be different in Debian and Ubuntu. I do not consider Ubuntu upstream to Debian. It makes much better sense to me to do coordinated work together on the Debian package. That said, I appreciate you informing about changes in Ubuntu, I will certainly cherry-pick changes that makes sense for Debian (which might very well be all of it). (and I speak only for myself - other maintainers may feel differently) Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkoZsEsACgkQn7DbMsAkQLghjQCfRLzJHT5+v4bXGK5YYdY2XDq1 Ql8Anip6to+HQGoc5ZUK4aLDiJeu3J0d =uTg3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hi Till and others, On Sun, May 24, 2009 at 08:44:43PM +0200, Till Kamppeter wrote: Please merge the following Ubuntu package version of Ghostscript into Debian: - pstoraster did not work when called with an input file name as the 6th command line argument. - The ps2write output device produces PostScript which is not DSC-conforming, so do not advertize it as DSC-conforming with a %!PS-Adobe-... magic string. Use %! instead. Otherwise the pstops CUPS filter cannot handle this output (https://bugs.launchpad.net/bugs/377011). - Fixed recognition of page size via /cupsPageSizeName in the cups output device. All page sizes were considered custom sizes if /cupsPageSizeName was not set. Above is in Git already (cherry-picked from upstream yesterday). Thank you very much. - Splitted off the CUPS-related files into its own package, so that the requirements of cups and cups-client for the automatic update of the PPDs of existing print queues do not apply to the ghostscript core package. Added cups and cups-client to the Depends: entry of the new ghostscript-cups package, so that the automatic updates of the PPDs also works on updates to a new release of the distribution and not only on single-package updates. Added also perl as dependency to the ghostscript-cups package as it is also needed for the automatic PPD updates. Sounds interesting. Is the perl dependency for the defoma code currently in ghostscript postinst? I haven't look closely at it, but is perl-base not sufficient? I have added the Perl dependency because the PPD updater in the ghostscript-cups.postinst script calls Perl, simply to do string manipulations with Perl's RE engine. If perl-base is enough for that purpose, please tell me, as I will add this dependency also to other packages (all printer drivers). I do not know what Defoma needs. I hope Defoma is dependent on that by itself, so that Ghostscript only needs to be dependent on Defoma. Could you please post a diff of this one change isolated - preferrably against the packaging work in Git? Or even better just applied directly to our Git here: git://git.debian.org/git/collab-maint/ghostscript.git. This is the diff between the Ubuntu package containing the ghostscript-cups split and the previous package. It contains exactly the changes done to do the split plus the dependency additions for the new package. http://launchpadlibrarian.net/26911463/ghostscript_8.64.dfsg.1-0ubuntu9_8.64.dfsg.1-0ubuntu10.diff.gz Especially the second and the last change are necessarily needed in Debian, to avoid that the CUPS packages have to be different in Debian and Ubuntu. I do not consider Ubuntu upstream to Debian. It makes much better sense to me to do coordinated work together on the Debian package. Me not, too. I suggest to overtake these changes into Debian, once to make it possible that the CUPS package can stay synced (be the same in both Debian and Ubuntu), and second, as the CUPS package in Debian is switched to the PDF printing workflow (http://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format), to fix bugs in Ghostscript which cause problems in the PDF printing workflow, mainly bugs in PDF - PostScript conversion. That said, I appreciate you informing about changes in Ubuntu, I will certainly cherry-pick changes that makes sense for Debian (which might very well be all of it). OK, I usually only ask Debian to ask for overtaking my changes in Ubuntu or upstream, if it simplifies the Debian/Ubuntu logistics or fixes important problems. As I am leading the OpenPrinting project I am often introducing new technologies into the printing infrastructure, and because I am Ubuntu developer they go to Ubuntu at first. The parts in CUPS they go automatically into Debian, as the CUPS packagfe is synced, but sometimes changes in CUPS depend on changes in other which are not synced. Thanks again for your cooperation. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Sun, May 24, 2009 at 11:09:18PM +0200, Till Kamppeter wrote: Jonas Smedegaard wrote: On Sun, May 24, 2009 at 08:44:43PM +0200, Till Kamppeter wrote: - Splitted off the CUPS-related files into its own package, so that the requirements of cups and cups-client for the automatic update of the PPDs of existing print queues do not apply to the ghostscript core package. Added cups and cups-client to the Depends: entry of the new ghostscript-cups package, so that the automatic updates of the PPDs also works on updates to a new release of the distribution and not only on single-package updates. Added also perl as dependency to the ghostscript-cups package as it is also needed for the automatic PPD updates. Sounds interesting. Is the perl dependency for the defoma code currently in ghostscript postinst? I haven't look closely at it, but is perl-base not sufficient? I have added the Perl dependency because the PPD updater in the ghostscript-cups.postinst script calls Perl, simply to do string manipulations with Perl's RE engine. If perl-base is enough for that purpose, please tell me, as I will add this dependency also to other packages (all printer drivers). I do not know what Defoma needs. I hope Defoma is dependent on that by itself, so that Ghostscript only needs to be dependent on Defoma. perl-base is sufficient if no modules are loaded, which is the case for the postinst routines. Perl-base is part of base so need not be declared as a dependency (except for versioned dependencies). You are right that defoma should care for its own dependencies. All in all: Please drop that perl dependency. Could you please post a diff of this one change isolated - preferrably against the packaging work in Git? Or even better just applied directly to our Git here: git://git.debian.org/git/collab-maint/ghostscript.git. This is the diff between the Ubuntu package containing the ghostscript-cups split and the previous package. It contains exactly the changes done to do the split plus the dependency additions for the new package. http://launchpadlibrarian.net/26911463/ghostscript_8.64.dfsg.1-0ubuntu9_8.64.dfsg.1-0ubuntu10.diff.gz Thanks. The Debian package has evolved, but above changes are pretty simple, so I can easily reimplement using the new packaging structure of 8.64-4. I hesitate doing it right now, however: this change is a new feature, not a bugfix, and adding new binary packages has a risk of delaying acceptance into Debian. I would therefore prefer to finalize the other changes currently released in experimental (I just released -4 a moment ago), and _after_ that implement this last change. What I want fixed for the package to enter unstable is this: a) symbols handling b) reduce linking c) coordination with dependent packages All three are related: Library symbols are supposed to be stable, but changes to compile flags change symbols, and recent changes even made some symbols disappear that was declared earlier on (libcairo was enabled for a short time, and at least on arm and i386 it offered some symbols that are now gone). I suspect that some symbols should not even be public, but do not understand library linking that well, so I might be completely off track here... I have cleaned up and added symbols since release of Lenny. But for some reason they are not used during install (probably some ordering issue between debhelper, CDBS and d-shlibdeps). the linking routine warns about excess linking. I do not know if fixing that affects symbols or not. When symbols are working properly to track changes at each release, we can contact package maintainers that link against ghostscript and coordinate with them to verify that nothing breaks linking against our cleaned up release. This seems to be only cups, foomatic-filters and libspectre, but I have checked only binary dependencies using aptitude, do not know how to look up source dependencies). As you might notice from above, I really am fumbling here - I am not a C library expert. So any help would be much appreciated. Oh, a related thing: I included a static library, as I believe is required by Debian Policy. But I suspect it is not compiled correctly: All code is currently compiled with -cPIC and if I recall correctly static library needs to be compiled _without_ -fPIC. Upstream build routines seem to handle -fPIC correctly - except for the X11 driver, which fails to build using --shared if -fPIC is not explicitly added to CFLAGS (causing it to be added twice in many places). So if I am right that static lib needs to not use -fPIC then the package needs to either a) patch ghostscript build routines related to X11 driver, or b) compile everything twice - once as now, and another without --shared or -fPIC. In addition to these, there is also a simpler task: check with
