On Wed, Jan 10, 2018 at 9:30 AM, David Kaspar [Dee'Kej]
<dkaspar@xxxxxxxxxx> wrote:
> On Wed, Jan 10, 2018 at 2:05 PM, Neal Gompa <ngompa13@xxxxxxxxx> 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!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
