Link to the draft
Link to diff
The Workstation Working Group would like to propose a packaging guideline to encourage independent packaging of applications. Some history of this discussion is available in the Workstation WG ticket, but note that the guidelines have evolved from my original proposal to be much less strict than originally proposed.
Background: GNOME Software does not currently handle the case where one application depends on another. This can cause applications to be unexpectedly installed when installing another application, or unexpectedly removed when removing another application. There is no clue to the user that the applications are related, and for the past few years we've considered this situation to be a packaging bug without ever having a formal rule for it. I proposed that we finally create that rule, and instead we wound up deciding to change GNOME Software to display the dependencies, which will be a much more robust solution anyway, since sometimes packagers really do need applications to depend on each other (e.g. a hypothetical video game level editor will surely want to depend on the video game).
But there is still value in adding guidelines to explicitly discourage this practice (without outright prohibiting it, as originally proposed), so that we have something to point to when it becomes an issue. We have a history of totally-unnecessary application interdependencies in Fedora, e.g. Java applications depending on strange Java control panel applications or log applications (log4j). Experience shows that it can be difficult to convince package maintainers to split the applications into subpackages in such cases, and having a guideline against it would be helpful when dealing with such situations.
Bonus: this draft change removes a stale reference to "X windows."
This seems reasonably sane to me.
Looks good apart from Use Enhances and Suggests instead. This doesn't make sense at all, it is used for making preferred choices where alternatives exist.
Use Enhances and Suggests instead.
Why are you saying that? From what I understand, that's not their sole or even primary application: https://fedoraproject.org/wiki/Packaging:Guidelines#Weak_dependencies
Why is the draft discouraging the use of Recommends and Supplements?
I'm just saying how it works today, nothing else =) They don't getting pulled in or installed in any way, they are just telling to libsolv preference of one or other package. While I would like to give it some meaning, it is not up to me now.
Because these dependencies will cause the extra application to be installed automatically, defeating half the point of avoiding the Requires. Switching to Recommends or Supplements is an improvement because it will allow the extra application to be removed, but we really want to avoid it having been installed in the first place.
In the very, very few cases where it really does make sense to install multiple applications at the same time, then Recommends or Supplements would be desired, but that should be very rare.
My understanding is that the point of Enhances is to point users of one package to another package without installing it by default, right? It's just a weak Recommends that doesn't actually take effect automatically. Hence the guidelines say to use this instead of Recommends. (Similarly, Suggests is a weak Supplements.)
We could definitely remove this sentence, so the guidance would be to use no dependencies at all, without any problems.
My understanding is that the point of Enhances is to point users of one package to another package without installing it by default, right?
Yes, but only way how user will see it is dnf repoquery --suggests foobar and decide to install something out of that... from my POV it is pointless to use that tag until we have some agreements with FPC/FESCo how we want to handle that tag.
dnf repoquery --suggests foobar
So I would just remove that sentence to not confuse people.
OK, I'll remove that sentence.
My expectation is that enhances and suggests would be displayed by the dnf package manager, just like package managers on other popular distros. But I guess that's not how it works now.
Forgot about this. Anything else needed from me to move this ticket forward?
I suppose we needed to add to it the meeting tag, so we can discuss further and/or vote on it :-)
Metadata Update from @mbooth: - Issue tagged with: meeting
We looked at this ticket this week, sorry for dropping this one for so long, (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-03-15/fpc.2018-03-15-16.00.txt):
...note that there was a huge amount of discussion for this ticket, but mcatanzaro was heavily involved.
Here's a new draft, based on the existing Libraries and Applications guidelines:
https://fedoraproject.org/wiki/PackagingDrafts/IndependentApplications
Diff: https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FIndependentApplications&type=revision&diff=517485&oldid=517484
For background, here's the meeting log from the previous time this draft was reviewed.
In particular, note:
17:16:53 <mcatanzaro> I think what I most want the guideline to convey is: packagers should think hard about the implications of graphical dependencies, and, in particular, graphical dependencies that are unnecessary. I don't want the guideline to ban creating dependencies where necessary, but we also want to really strongly discourage dependencies that don't make sense 17:16:54 <mcatanzaro> . E.g. libraries that install a developer application, like Java control panel, or the old tracker preferences, or libgda database viewer, should definitely be packaged separately.
This did get approved during the meeting but I don't think the tickets have been updated. I will have some time this weekend, so I'm adding this to my work list.
Metadata Update from @tibbs: - Issue untagged with: meeting - Issue assigned to tibbs - Issue tagged with: writeup
We spoke about this ticket in last weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-05-03/fpc.2018-05-03-16.01.txt):
Announcement text:
The Libraries and Applications section of the guidelines was modified to favor independent packaging of applications and to discourage separate graphical applications from having dependencies on each other.
Metadata Update from @tibbs: - Issue untagged with: writeup - Issue tagged with: announce
Metadata Update from @tibbs: - Issue untagged with: announce - Issue close_status updated to: accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.