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
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.
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.
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.
OK, I understand.
Feel free to continue posting bugs as you do now. I just imagine us
working more effectively another way :-)
OK
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
