-----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 PPDs of existing print queues. Oh, I wasn't aware that the switch had already occured for Debian :-P Thanks for clarifying. >> 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. >> > > I have an Alioth account already, due to my write access to CUPS. User > name is till-guest. 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. 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) iEYEAREDAAYFAkoaW6gACgkQn7DbMsAkQLjtRwCeIUuG6TzAfM6fL8MhV4AAtKJB 89oAn331LFZ9Mb0sL/qw52EikT9RD8+d =85kp -----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
