Re: HEADS UP - Changes to Ghostscript package in F28

2018-02-19 Thread David Kaspar [Dee'Kej] 
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:
https://fedoraproject.org/wiki/Changes/GhostscriptPackageUpdate28

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: https://bugzilla.redhat.com/
show_bug.cgi?id=1534638

The mass rebuild of F28 is done, and I'm aware only about one FTBFS related
to these changes:
https://bugzilla.redhat.com/show_bug.cgi?id=1535860 (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 .
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-19 Thread David Kaspar [Dee'Kej] 
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 
wrote:

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

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



> 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?
>

​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:
https://koji.fedoraproject.org/koji/fileinfo?rpmID=12537549=/usr/share/ghostscript/Resource/Init/gs_resmp.ps
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-17 Thread Michael Cronenworth 

On 01/09/2018 04:51 PM, David Kaspar [Dee'Kej] wrote:
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...


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?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-11 Thread David Kaspar [Dee'Kej] 
On Wed, Jan 10, 2018 at 7:50 PM, Adam Williamson  wrote:

> On Wed, 2018-01-10 at 10:45 +0100, Kamil Dudka wrote:
> > On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote:
> > > 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.
> >
> > It would be better to create a Copr for testing purposes to avoid
> disruption
> > of Fedora development.
>
> +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.
>

​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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread Adam Williamson 
On Wed, 2018-01-10 at 10:45 +0100, Kamil Dudka wrote:
> On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote:
> > 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...
> 
> 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.
> 
> > 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.
> 
> It would be better to create a Copr for testing purposes to avoid disruption 
> of Fedora development.

+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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread David Kaspar [Dee'Kej] 
On Wed, Jan 10, 2018 at 3:44 PM, Neal Gompa  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.
>

​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. (
https://src.fedoraproject.org/rpms/ghostscript)


> 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...
>

​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. :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread Neal Gompa 
On Wed, Jan 10, 2018 at 9:30 AM, David Kaspar [Dee'Kej]
 wrote:
> On Wed, Jan 10, 2018 at 2:05 PM, Neal Gompa  wrote:
>>
>> 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.
>
> I'm not aware of any BZ/Fedora wiki page that is requiring this. This
> solution was based solely on my best judgment. To clarify on this:
>
> 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. :)
>
>

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.

>> Why are examples not shipped? For documentation, this seems to be
>> fine, especially since it's a separate subpackage anyway.
>
> Upstream has decided to drop the examples/ completely from the next version
> of Ghostscript release (9.23). According to them those files are more useful
> for testing purposes rather than actual examples, and those files are poorly
> written PostScript files. They wouldn't help people who would like to learn
> how to write PostScript documents. That's why upstream does not want to ship
> those files anymore.
>
> 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.
>
>

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

>>
>> > * 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.
>> >
>>
>> 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.
>
>
> 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:
> https://www.freedesktop.org/wiki/Software/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.

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread David Kaspar [Dee'Kej] 
On Wed, Jan 10, 2018 at 3:30 PM, David Kaspar [Dee'Kej] 
wrote:

> I hope I didn't forget to mention something important... :D If something
> is unclear, lay it on me! ;)
>
​
Yeah, I forgot one more small thing to mention... :D For now I'm waiting
for 'google-droid-fonts' to be rebased to latest version, to make sure that
the upstream's default solution for CJK-based documents missing embedded
fonts ​is up-to-date. (https://bugzilla.redhat.com/show_bug.cgi?id=1532523)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread David Kaspar [Dee'Kej] 
On Wed, Jan 10, 2018 at 2:05 PM, Neal Gompa  wrote:

> 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.
>
​I'm not aware of any BZ/Fedora wiki page that is requiring this​. This
solution was based solely on my best judgment. To clarify on this:

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
> fine, especially since it's a separate subpackage anyway.
>
​Upstream has decided to drop the examples/ completely from the next
version of Ghostscript release (9.23). According to them those files are
more useful for testing purposes rather than actual examples, and those
files are poorly written PostScript files. They wouldn't help people who
would like to learn how to write PostScript documents. That's why upstream
does not want to ship those files anymore.

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.​



> > * 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.
> >
>
> 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.
>

​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: https://www.freedesktop.org/wiki/Software/
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

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread Neal Gompa 
On Tue, Jan 9, 2018 at 5:51 PM, David Kaspar [Dee'Kej]
 wrote:
> 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...
>

Overall, I think this is awesome. Just some questions and nits below...

> ->> 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).
>

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.

> * 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.
>

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

> * 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.
>

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.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread Kamil Dudka 
On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote:
> 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...

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.

> 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.

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

Kamil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

HEADS UP - Changes to Ghostscript package in F28

2018-01-09 Thread David Kaspar [Dee'Kej] 
​​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: https://src.fedoraproject.org/rpms/libijs

* 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:

  https://src.fedoraproject.org/rpms/adobe-mappings-cmap
  https://src.fedoraproject.org/rpms/adobe-mappings-pdf
  https://src.fedoraproject.org/rpms/libijs
  https://src.fedoraproject.org/rpms/urw-base35-fonts
  https://src.fedoraproject.org/rpms/google-droid-fonts

->> 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.