On Wed, Jan 10, 2018 at 3:44 PM, Neal Gompa <ngomp...@gmail.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.
>
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
