On Wed, Jan 10, 2018 at 9:30 AM, David Kaspar [Dee'Kej]
<dkaspar(a)redhat.com> wrote:
On Wed, Jan 10, 2018 at 2:05 PM, Neal Gompa
<ngompa13(a)gmail.com> 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. 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. :)
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...
--
真実はいつも一つ!/ Always, there's only one truth!