On Wed, Jan 10, 2018 at 3:44 PM, Neal Gompa <ngompa13@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
