-----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 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. 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. If not interested, then it makes better sense to me that the Debian package cherry-picks patches from upstream ghostscript than do it from (as I see it) downstream Ubuntu. >> 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. Feel free to continue posting bugs as you do now. I just imagine us working more effectively another way :-) > 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. ok. - 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) iEYEAREDAAYFAkoZxg8ACgkQn7DbMsAkQLgklACfdYqcubsgD6z0Xr7Cc5fFnti6 +3gAoIsPhLo5+QO5nTNWy19OpCebDTJh =zasJ -----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
