DevHeads.net

HEADS UP - Changes to Ghostscript package in F28

​​Hello guys! :)

Initial NOTE: I have made some bigger changes in Ghostscript package during
the cleanup, which should be self-contained. In my opinion those changes
are not so significant to create "self-contained change" wiki page for it
(for F28), but if the consensus of people here will be the opposite, then I
will create it additionally...

I would like to inform you that Ghostscript package has received proper
cleanup in accordance to Fedora Packaging Guidelines (FPG), and comments
from upstream were also incorporated into the changes.

The aim was to simplify the package maintenance, to bring the Fedora's
Ghostscript package as close as possible to upstream's vanilla build, to
completely debundle the Ghostscript package of software/resources that we
already have available (packaged) in Fedora, and to transform the layout of
subpackages to be more sane and granular...

The changes are described more in detail below:

* libijs -- the IJS library has been debundled and is now provided as a
separate package: <a href="https://src.fedoraproject.org/rpms/libijs" title="https://src.fedoraproject.org/rpms/libijs">https://src.fedoraproject.org/rpms/libijs</a>

* libgs -- new separate package, created from Ghostscript's shared library.
It contains all necessary files for other software/packages that are build
upon Ghostscript's functionality.
* libgs-devel -- new separate subpackage, for development purposes or
Fedora's build process. The 'ghostscript-devel' is still provided for now
as a virtual subpackage.

->> This particular change will allow packages depending on Ghostscript
functionality (like evince for example) to only require 'libgs', instead of
requiring almost the whole Ghostscript (and thus pulling in files that many
users don't want/need or might even never use).

* ghostscript -- is no longer a metapackage. It's a regular package
instead, and it contains Ghostscript's binaries as well as some typical
conversion scripts people are used to (and expect to have
installed together with Ghostscript by default).

* ghostscript-tools-fonts -- new subpackage that contains 3 scripts that
are useful only for people who are working with AFM, PFB or PFA files
(conversions usually).
* ghostscript-tools-printing -- new subpackage that contains only utilities
for formatting and printing text files using either Ghostscript, or
BubbleJet, DeskJet, DeskJet 500, & LaserJet printers.

->> These subpackages contain files that only a small amount of people will
ever need. Having them in a separate subpackages will avoid polluting
users' filesystem after fresh F28+ installations.

* ghostscript-core -- has became an empty metapackage for upgrade purposes.
It will be removed once Fedora 28 is EOL, and all other packages has
updated their specfiles to require correct subpackages.

->> This metapackage makes sure that upgrade from old package layout to new
package layout should be smooth (tested in F27).

* LPR setup scripts are no longer being shipped. In case people still need
those, then 'ghostscript-tools-lpr' will be created for it.
* examples/ from 'ghostscript-doc' are no longer shipped.
* Documentation and resources paths no longer contain version string inside
of them.

* Support for /usr/share/ghostscript/conf.d/ folder was dropped to use
Ghostscript's default choice for rendering of CJK glyphs, which is Google
Droid Sans Fallback font. In case this proves insufficient, the conf.d/
folder support will be re-established.

->> This change is still being discussed with Peng Wu and Akira Tagoh. So
far, we have agreed to this change, but I will be ready to revert it in
case people depending on printing CJK-based texts will have any problems.
In case the Ghostscript's default functionality would prove to be sufficent
and work OK, then the 'ghostscript-chinese' package could be retired as a
result.
->> For now, we are also waiting for rebase of 'google-droid-fonts' for
Ghostscript to have the latest version of Droid Sans Fallback font and thus
the latest CJK glyphs coverage.

* Symbolic links for direct resources locations have been added to speedup
Ghostscript's startup time.
* Ghostscript's search path was updated to include only fonts locations,
which will be used only as a backup (in case of broken symbolic links).

->> This change is a preferred method (advised) from upstream.

* Ghostscript itself (as a whole) has been completely debundled (to a
point where it still makes sense). It newly requires these packages:

<a href="https://src.fedoraproject.org/rpms/adobe-mappings-cmap" title="https://src.fedoraproject.org/rpms/adobe-mappings-cmap">https://src.fedoraproject.org/rpms/adobe-mappings-cmap</a>
<a href="https://src.fedoraproject.org/rpms/adobe-mappings-pdf" title="https://src.fedoraproject.org/rpms/adobe-mappings-pdf">https://src.fedoraproject.org/rpms/adobe-mappings-pdf</a>
<a href="https://src.fedoraproject.org/rpms/libijs" title="https://src.fedoraproject.org/rpms/libijs">https://src.fedoraproject.org/rpms/libijs</a>
<a href="https://src.fedoraproject.org/rpms/urw-base35-fonts" title="https://src.fedoraproject.org/rpms/urw-base35-fonts">https://src.fedoraproject.org/rpms/urw-base35-fonts</a>
<a href="https://src.fedoraproject.org/rpms/google-droid-fonts" title="https://src.fedoraproject.org/rpms/google-droid-fonts">https://src.fedoraproject.org/rpms/google-droid-fonts</a>

->> I will send additional separate e-mails to this mailing list tomorrow
to inform others of availability of some of these packages.

* As a result of debundling, 'poppler-data' is no longer a requirement for
Ghostscript, and it is no longer necessary to do a rebuild of
'poppler-data' when Ghostscript is rebased.

These changes shouldn't influence most of the users in any significant way.
Some of Fedora developers might need to update their specfiles to require
correct new (sub)package names. For that I will create a new tracking BZ
for all related packages, and I will create necessary pull-requests on
Pagure, or open corresponding BZs if pull-requests are disabled.

The new Ghostscript should be available for trying/testing in Rawhide in a
few hours. I will follow up with additional information (e.g. tracking BZ
link) here in this thread.

Best regards,

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.

Comments

Re: HEADS UP - Changes to Ghostscript package in F28

By Michael Cronenworth at 01/17/2018 - 11:01

On 01/09/2018 04:51 PM, David Kaspar [Dee'Kej] wrote:
You should create a change request for this. It's very significant, IMHO.

I've encountered a problem with this change. ImageMagick tests require the
'gs_resmp.ps' resource file to be around, but I cannot find where this file lives
now. Where is it now?

Re: HEADS UP - Changes to Ghostscript package in F28

By David Kaspar at 01/19/2018 - 08:48

Hello guys!

I wanted to let you know I have decided to create additional subpackage
'ghostscript-tools-dvipdf' after some discusssions. It is because the
'dvipdf' tool requires 'dvips' utility to work correctly, which is provided
in 'texlive-dvips' subpackage. This resulted in lot of texlive packages
being pulled in as a dependency of 'ghostscript' where the 'dvipdf' tool
initially was.

However, many of our users might not need the 'dvipdf' tool nor the texlive
itself. This change might cause some inconvenience to some users, but for
most of the people it should save them some disk space when they don't need
the texlive installed.

Also, the new 'ghostscript-tools-dvipdf' subpackage is not required by
'ghostscript-core' meta subpackage. This will ensure that users doing
upgrade to F28 will not get texlive automatically installed in case they
didn't have it before.

On Wed, Jan 17, 2018 at 4:01 PM, Michael Cronenworth < ... at cchtml dot com>
wrote:

​OK, I'll start working on that once I all the necessary packages in the
tracking BZ.

​The file is generally located in Resource/Init folder of Ghostscript. As I
mentioned before, the version of the Ghostscript is no longer part of this
path:
/usr/share/ghostscript/*9.22*/Resource/Init/gs_resmp.ps ->>
/usr/share/ghostscript/Resource/Init/gs_resmp.ps

It is part of the 'libgs' package now:
<a href="https://koji.fedoraproject.org/koji/fileinfo?rpmID=12537549&amp;filename=/usr/share/ghostscript/Resource/Init/gs_resmp.ps" title="https://koji.fedoraproject.org/koji/fileinfo?rpmID=12537549&amp;filename=/usr/share/ghostscript/Resource/Init/gs_resmp.ps">https://koji.fedoraproject.org/koji/fileinfo?rpmID=12537549&amp;filename=/us...</a>

Re: HEADS UP - Changes to Ghostscript package in F28

By David Kaspar at 02/19/2018 - 09:03

Hello guys,

and sorry for the delay - I've got caught in my other responsibilites. I
have created the Wiki page for this change, as requested:
<a href="https://fedoraproject.org/wiki/Changes/GhostscriptPackageUpdate28" title="https://fedoraproject.org/wiki/Changes/GhostscriptPackageUpdate28">https://fedoraproject.org/wiki/Changes/GhostscriptPackageUpdate28</a>

To comply with the guidelines there, I had to categorize this as a
"system-wide change" though.

The pull-requests to update specfiles for all the dependant packages have
been already submitted. Some of them were already accepted. You can see the
progress in this tracking BZ: <a href="https://bugzilla.redhat.com/" title="https://bugzilla.redhat.com/">https://bugzilla.redhat.com/</a>
show_bug.cgi?id=1534638

The mass rebuild of F28 is done, and I'm aware only about one FTBFS related
to these changes:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1535860" title="https://bugzilla.redhat.com/show_bug.cgi?id=1535860">https://bugzilla.redhat.com/show_bug.cgi?id=1535860</a> (upstream is already
aware of this issue)

Best regards,

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.

Re: HEADS UP - Changes to Ghostscript package in F28

By King InuYasha at 01/10/2018 - 09:05

On Tue, Jan 9, 2018 at 5:51 PM, David Kaspar [Dee'Kej]
< ... at redhat dot com> wrote:
Overall, I think this is awesome. Just some questions and nits below...

Is there a specific bug that forces us to require we have transitional
packages like this? RPM's Conflicts+Obsoletes logic is powerful enough
to allow us to avoid this.

Why are examples not shipped? For documentation, this seems to be
fine, especially since it's a separate subpackage anyway.

I'm confused why we would drop support for conf.d directories. Unless
it's completely unavoidable, I don't see why we would do this. We
can't possibly know of everyone who might be using them, and generally
speaking, I'd like to see more software configurable this way, not
less.

Re: HEADS UP - Changes to Ghostscript package in F28

By David Kaspar at 01/10/2018 - 10:30

The 'ghostscript-core' is a "main" subpackage in previous subpackage
scheme. It basically contained almost everything from Ghostscript's
compilation, and IIRC few of other packages were requiring this package
directly in their specfiles...

Other packages were not yet updated to requires correct subpackage from new
subpackage layout. Therefore I decided to transform 'ghostscript-core' into
auxiliary subpackage, since it was already there.

This should have allowed new Ghostscript to be rolled out without breaking
build process for them (hopefully completely, or at least it should at
mitigate most of the problems). And the other packages can be then rebuild
immediately once their requirements have been appropriately updated. :)

Why are examples not shipped? For documentation, this seems to be
Since I was doing changes to contents/layout of Ghostscript, I thought it
was a good time to incorporate this change into the package already.​

​The folder /usr/share/ghostscript/conf.d/ actually comes from the package
'ghostscript-chinese'. Ghostscript itself was just configured to check that
folder for configuration before, if there was any.

The folder itself contained mappings for specific locales into
specific CJK-based
fonts. It was used only after 'ghostscript-chinese' was installed. This
solution was introduced into Ghostscript more than a decade ago, and it is
based on ​this project: <a href="https://www.freedesktop.org/wiki/Software/" title="https://www.freedesktop.org/wiki/Software/">https://www.freedesktop.org/wiki/Software/</a>
CJKUnifonts/

If you look at the project, you will that it is basically dead, and the
'ghostscript-chinese' package itself received last update in 2012.

The main purpose of using 'ghostscript-chinese' is to introduce a
workaround for displaying/printing of CJK-based documents which do not have
the correct font embedded (for displaying the glyphs inside the document
text). When document wouldn't have correct CJK font(s) embedded inside it,
then Ghostscript would the closest substitution(s), so the document can be
at least displayed/printed in a readable/legible way. However, the
substitution will never be perfect, and will always be best-effort
workaround.

The above described situation was valid several years ago. Nowadays
upstream has its own solution (i.e. workaround) on doing so, which is based
only on one (different) font - Google Droid Sans Fallback.

I'm still discussing this change with Peng Wu (maintainer of
'ghostscript-chinese') and Akira Tagoh (fontconfig upstream developer)
off-the-list, but for now we have agreed to try use the default upstream's
solution for this scenario.

If it works well, this should mean less maintenance work for Peng
('ghostscript-chinese' could be dropped), and we wouldn't have a downstream
solution that could potentially cause additional issues in the future.
Also, the downstream solutions were really not popular with upstream before
(IMHO they didn't like Fedora at all because of it), and I was working with
them for last half and a year to improve our relationship with them from
Fedora side. :)

I hope I didn't forget to mention something important... :D If something is
unclear, lay it on me! ;)

Re: HEADS UP - Changes to Ghostscript package in F28

By King InuYasha at 01/10/2018 - 10:44

On Wed, Jan 10, 2018 at 9:30 AM, David Kaspar [Dee'Kej]
< ... at redhat dot com> wrote:
If the content of "ghostscript-core" is now part of "ghostscript", you
can do the following:

Obsoletes: ghostscript-core < 9.22-5
Provides: ghostscript-core = %{version}-%{release}

In addition, packages that currently require "ghostscript-core" can
and should be fixed for Fedora 28. In my view, there's nothing that
necessitates this metapackage for a development branch.

If this was going into Fedora 27, for example, then sure, it makes sense.

Makes sense to me. Thanks for the detailed rationale. :)

Okay, this makes sense. I'm a bit disappointed that we couldn't have
the conf.d thing upstreamed, but we'll see how it goes...

Re: HEADS UP - Changes to Ghostscript package in F28

By David Kaspar at 01/10/2018 - 11:55

​Unfortunately in the current situation, it's not that simple... :-/ Let me
try to explain:​

In the context of changes mentioned here (package layout change,
software/resources debundling) specifying Obsoletes/Provides as you
mentioned above for 'ghostscript' (or any other subpackage) wasn't enough.
As I said before, the 'ghostscript-core' contained almost everything from
Ghostscript's build, and 'ghostscript' was an empty metapackage, requiring
'ghostscript-core', 'ghostscript-x11'.

If I would specify the Obsoletes/Provides inside 'ghostscript' package as
you suggest, then the 'ghostscript' package would still miss some scripts
that are now in separate subpackages (*-tools-*). It could lead to people
complaining (in BZs, mailing list) about missing scripts after upgrade to
F28 (the scripts would have been uninstalled during upgrade in this way).
I'm trying to avoid any disturbance to our users that could generally lead
to negative feelings about our distribution.

In order to have the scripts kept during the upgrade, then I would have to
specify additional requirements in 'ghostscript' package for the
'ghostscript-tools-*' subpackages. However, this would create again the
problem I was trying to solve in the first place (to have more granular
package layout), and 'ghostscript' package itself would just become "new"
'ghostscript-core'. I.e., the contents would have been moved from
'ghostscript-core' into 'ghostscript', which is not exactly what I wanted.
:)

So right now, none of the (sub)package has Obsoletes/Provides/Requires for
'ghostscript-core'. Instead, I kept the 'ghostscript-core' with
requirements on 'libgs', 'ghostscript', 'ghostscript-tools-*'. This way the
'ghostscript-core' will not be installed automatically on fresh F28
installations, but for users upgrading from previous version to F28, it
will kept the Ghostscript scripts installed.

My plan is to remove the 'ghostscript-core' once F28 has reached EOL. I
realize now that this might influence the users doing the upgrade anyway
(the 'ghostscript-tools-*' might get uninstalled during upgrade and some of
them might be missing them). But before I need to deal with this, I want to
make sure other packages requiring Ghostscript are fixed first. To kind of
grind the huge change into a smaller chunks of changes, if possible. :)

I'm sorry if my explanation does not make sense. :-/ If that's the chase,
then it might be better to look in the specfile at the package layout (and
dependencies) before and after the change. (
<a href="https://src.fedoraproject.org/rpms/ghostscript" title="https://src.fedoraproject.org/rpms/ghostscript">https://src.fedoraproject.org/rpms/ghostscript</a>)

​Generally it's hard to get something upstreamed unless they have any
benefit from it. I had really hard times trying to convince them to create
a new Github repository for 'urw-base35-fonts' and accepting the AppStream
and fontconfig configuration files there.

For upstream accepting something might mean additional maintenance ​work,
and they are (understandably) trying to avoid it. :)

Re: HEADS UP - Changes to Ghostscript package in F28

By David Kaspar at 01/10/2018 - 10:33

On Wed, Jan 10, 2018 at 3:30 PM, David Kaspar [Dee'Kej] < ... at redhat dot com>
wrote:

Re: HEADS UP - Changes to Ghostscript package in F28

By Kamil Dudka at 01/10/2018 - 05:45

On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote:
As far as I understand, this is going to affect how other packages are built,
installed, and run. It should be reviewed by the affected parties to decide
whether it is a self-contained or system-wide change and the respective
process should be followed.

It would be better to create a Copr for testing purposes to avoid disruption
of Fedora development.

Kamil

Re: HEADS UP - Changes to Ghostscript package in F28

By Adam Williamson at 01/10/2018 - 14:50

On Wed, 2018-01-10 at 10:45 +0100, Kamil Dudka wrote:
+1 (or a tag). Lots of stuff hangs off of ghostscript. It'd be nice to
have the implications of this at least broadly figured out in advance
rather than "doing it live" in Rawhide.

Re: HEADS UP - Changes to Ghostscript package in F28

By David Kaspar at 01/11/2018 - 08:09

On Wed, Jan 10, 2018 at 7:50 PM, Adam Williamson < ... at fedoraproject dot org

​I was trying to make the F28 planning phase deadline, in case people would
require to create System-wide / Self-contained change​ wiki page for it. In
the rush I didn't think of your point, and automatically submitted 'fedpkg
build'.

But I agree with your point. I will try to be more aware of this in the
future, to not repeat this mistake again.