Description of problem: There's b0rken compatibility for the ghostscript-core package. Maintainer refuses to provide proper compatibility layer. Version-Release number of selected component (if applicable): rawhide How reproducible: yes Steps to Reproduce: 1. dnf install ghostscript-core 2. dnf repoquery --whatprovides ghostscript-core 3. Actual results: ghostscript-libs gets installed or found, still. Expected results: Keep the Obsoletes line to not break compatibility. Additional info: https://src.fedoraproject.org/rpms/ghostscript/blob/e408b6316d96b847401bb4be6e2d1c3a754b2258/f/ghostscript.spec#_141
Justification from maintainer can be found in https://bugzilla.redhat.com/show_bug.cgi?id=1536575#c4
> Expected results: > Keep the Obsoletes line to not break compatibility. Obviously, we need as well: Provides: ghostscript-core Please remove Conflicts line.
I would tend to agree with the reporter here, better way forward would be replacing: in libgs: Conflicts: %{name}-core%{?_isa} < %{conflicts_vers} (which doesn't actually work due to the inclusion of %{?_isa}) with (in main pkg): Obsoletes: %{name}-core < %{conflicts_vers} Provides: %{name}-core = %{version}-%{release} where at some point in the future, * you can drop the Provides (as early as f29) * you can drop the Obsoletes (as early as f30)
Further: [07.03.18 20:33] <gholms> It isn't like Fedora packages are the only things that depend on gs.
https://src.fedoraproject.org/rpms/ghostscript/pull-request/1
(In reply to Rex Dieter from comment #3) > I would tend to agree with the reporter here, better way forward would be > replacing: > > in libgs: > Conflicts: %{name}-core%{?_isa} < %{conflicts_vers} > > (which doesn't actually work due to the inclusion of %{?_isa}) > > with (in main pkg): > Obsoletes: %{name}-core < %{conflicts_vers} > Provides: %{name}-core = %{version}-%{release} > > where at some point in the future, > * you can drop the Provides (as early as f29) > * you can drop the Obsoletes (as early as f30) Hello Rex, thank you for the input. :) Unfortunately, that will not work. The ghostscript-core still exists in the form of meta-package for transitional purposes to new package layout of Ghostscript: https://src.fedoraproject.org/rpms/ghostscript/blob/master/f/ghostscript.spec#_242 I have fixed (removed) the %{isa} for the Conflicts there, but that's all what I will do for it, because the change from pull-request would break things, and it would also negate all the purpose and outcome of the Ghostscript's change... 1) The change was discussed on a fedora-devel mailing list extensively, where I was explaining people the reasons for these changes, and we were discussing possible caveats. The mailing list thread is here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5NRUY6KBN6RYM2D6WJIVQZ4HZ4EI2O2Z/ 2) The change is also documented on our Fedora wiki: https://fedoraproject.org/wiki/Changes/GhostscriptPackageUpdate28 3) The change was discussed with some of the Fedora's Proven Packager, as well with some other maintainers. 4) The only change that is needed from Raphael was to merge the pull-request I have prepared for him. Once we would actually do it, then he wouldn't notice a difference in his shrinkpdf package at all. For him, everything would work as before. (Not even a rebuild was required from him.) 5) From 36 packages Raphael is the only maintainer making a fuss about it (basically merging pull-request with one-liner change) and resisting the change. 6) Not even Graphviz or ImageMagick maintainers had problems with the change. I really don't expect one small bash script (wrapper around GS) to be suffering any problems from this change. As I said - the change for shrinkpdf is transparent... It's not my problem Raphael didn't read the e-mail thread or the wiki page, and he's still refusing to merge one small pull-request while at the same time the change is actually not affecting him at all... I don't know why Raphael tries to play that one annoying guy resisting something which is not actually affecting him significantly in any way (to say it politely). Even the work has been done for him - the only thing needed from him was pressing the MERGE button... Even if he takes this to FESCo, I'm standing behind the current Ghostscript packaging, and I'm not going back just because he doesn't like it. They will be always people resisting change for no obvious reasons, and if we would allow them to stop us everytime, then we would never improve Fedora at all. :) Best regards, -- Dee'Kej --
OK, the real problem is specific implementation details, not the idea in general. Looking closer... 1. libgs: # FIXME: Remove the line below once F28 is EOL. Conflicts: %{name}-core < %{conflicts_vers} This is legit, though the packaging could have been engineered to avoid it. 2. libgs-devel: # FIXME: Remove the lines below once F28 is EOL. Conflicts: %{name}-devel < %{conflicts_vers} Obsoletes: %{name}-devel < %{conflicts_vers} You don't need both, only Obsoletes, please remove the Conflicts here. 3. ghostscript-core: You chose to keep a -core metapackage (I missed seeing that before), which is fine for now. When you to remove -core, *something* will need to replace it, however (that's the part I and reporter were concerned about), and that will require an Obsoletes as I and the PR suggested. *typically* that's also accompanied by a Provides: to also ease upgrade paths and expectations.
(In reply to Rex Dieter from comment #7) > OK, the real problem is specific implementation details, not the idea in > general. Looking closer... > > 1. libgs: > > # FIXME: Remove the line below once F28 is EOL. > Conflicts: %{name}-core < %{conflicts_vers} > > This is legit, though the packaging could have been engineered to avoid it. Well, the packagin was a complete mess before. This is just a result of it, when I was doing a cleanup... IIRC, it was needed for doing correct upgrade to new version from the old version of Ghostscript. > 2. libgs-devel: > > # FIXME: Remove the lines below once F28 is EOL. > Conflicts: %{name}-devel < %{conflicts_vers} > Obsoletes: %{name}-devel < %{conflicts_vers} > > You don't need both, only Obsoletes, please remove the Conflicts here. I can't recall exactly right now the details, but for some reason I had to have both of these lines for Ghostscript to upgrade correctly. I intend to remove those lines once F28 is EOL, as the comment suggests. :) Or do you think it's really necessary to remove it now? As I said, the upgrade process should work as intended. > 3. ghostscript-core: > > You chose to keep a -core metapackage (I missed seeing that before), which > is fine for now. Yes, and it was mentioned both in the mailing list and the wiki page. > When you to remove -core, *something* will need to replace it, Yes, and that something what replaces it is *ghostscript* package itself. :) I have gone the lengths to make sure all the dependant packages (which were requiring ghostscript-core) were updated to use new correct requirements. > however > (that's the part I and reporter were concerned about), and that will require > an Obsoletes as I and the PR suggested. *typically* that's also accompanied > by a Provides: to also ease upgrade paths and expectations. Once all 36 packages are correctly updated, and in the same time the F28 is retired, then we can drop the ghostscript-core without the need of something providing the 'ghostscript-core'. Because at that time, there shouldn't be any packages that require the ghostscript-core, so it can be safely dropped. :) Anyway, if we will still need the 'ghostscript-core' to be provided for some reason by some package, then it will have to be put into 'ghostscript' itself, which is the closest thing to previous contents of 'ghostscript-core'. Adding it into 'libgs' won't be sufficent, because that's a not complete Ghostscript, but just a library. ;) These changes to Ghostscript took a lot thoughts, planning, and effort. I was trying to do my best to not disturb anyone's packages requirements, builds, and to have almost zero to none disturbance to our Fedora users. :) When something comes up, I try to deal with it quickly as well. So far it was IMHO a successful change. If you have any more questions, I'm OK to discuss it more.
David, thanks for taking the time to explain the issue in details and the reasonable clarification. Really appreciated!
(In reply to Raphael Groner from comment #9) > David, thanks for taking the time to explain the issue in details and the > reasonable clarification. Really appreciated! I'm glad we got on the same side here! :) I never intended to wage "flame-war" about packaging with anyone, and I think you didn't either. :)