Adjust text of Package Independence guidelines #1456
Labels
No labels
announce
bootstrap
Closed As
accepted
Closed As
duplicate
Closed As
exceptionexpired
Closed As
fixed
Closed As
invalid
Closed As
nothingtodo
Closed As
permanentexception
Closed As
rejected
Closed As
temporaryexception
Closed As
wontfix
cmake
committee
draftneeded
hasdraft
meeting
meson
needinfo
Priority
In Committee
Priority
Needs Review
Priority
Waiting For Reporter
rust
writeup
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
packaging/guidelines#1456
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi, this is a follow-up to #694 which added the application independence guidelines:
Suggested change:
The goal is to generalize the rule to discourage all packages from depending on desktop applications except in special circumstances like plugins. Case in point is this bug report where hplip-gui is being installed if both hplip and qt5-qtbase-gui are also installed. This should surely be strongly discouraged, but neither hplip nor qt5-qtbase-gui contains a desktop application, and the current text of the packaging guidelines only applies to desktop applications.
Makes sense to me.
Change makes sense in general, but some wordsmithing might be required not to exclude some cases where depending on a desktop app makes sense ( @carlgeorge mentioned gnome-shell extensions Recommending the gnome shell extension app, which makes sense to me, since there would be no way to enable those extensions without the app).
(Matrix seems to be offline for me, so commenting here so it's not lost.)
Also note that hplip-gui could still "Supplements: hplip if qt5-qtbase-gui"
Is that fine or do you want extra wording to at least suggest people not do that?
Metadata Update from @james:
I think this is explicitly a case where we don't want this. :)
Speaking for myself, I found it very Windows-esque that suddenly some weird HP software got installed on my machine.
Actually I don't think that's a good example: you really should be able to install an extension without pulling in a graphical app.
I had intended "unless strictly required" to leave some wiggle room only for cases where it really never makes sense to not depend on the app.
You're right, and it's not fine. The problem is Supplements works by reverse, so we need to reverse the text as well. Amended proposal:
@decathorpe
See, that's the funny thing about this --- the weird HP software was already installed on your machine.
This came about because
hplipstarted (at my request) Recommending its own GUI subpackage (conditionally, if the Qt gui package is also installed)... which causedhplip-guito be newly pulled in on systems withhplipalready installed. Which is most of them, becausehplipis a default package.IOW, nothing new was actually installed. You already had the weird HP software. But the icons for it weren't installed, which means it was previously there but hidden from view.
(And as I said in the bugzilla bug, I get why that's an issue for people. The "what they don't know won't hurt them" principle applies.)
@catanzaro
You might want to throw a couple of explicit "or subpackage"-s in there, since as worded this still sounds like it's only about wholly separate packages depending on each other, and not necessarily about even base packages depending on their own subpackages.
(I also don't think it would hurt to go into the reasons for this rule a bit, instead of just dumping it out there as a "because we say so".)
Funny, the list of contents of hplip-gui is rather long:
https://src.fedoraproject.org/rpms/hplip/blob/rawhide/f/hplip.spec#_936-969
This suggests that new things were, indeed, installed ...
We talked about this a bunch in today's meeting ... the general consensus was that making this hard rule more general is probably bad, and what we kind of want to say is something like:
"If a user installs package X the resulting package list should surprise them the least amount possible."
...obviously this is very subjective, but maybe we could have a couple of different user viewpoints (Eg. old sysadmin guy installing a headless server without weakdeps. And a newer user installing something that looks fun/useful).
If you could provide better wording for the above, that'd be great.
If you want to try a different approach, feel free but be warned that there was a lot of disagreement about this (Eg. the initial generic wording probably breaks KDE).
I don't want to harp on this because I realize it's off-topic for the issue, but:
Yes, files were installed by hplip-gui. 2.2 MBs' worth of them, in fact. But those files consist entirely of:
.desktopfiles for those graphical tools/usr/bin/to the various/usr/share/hplip/Python modules that implement those toolsThe tools themselves — graphical and console based alike — are all installed in
/usr/share/hplip/by thehplippackage. It's only the GUI components' visibility to the user that gets wired up byhplip-gui. That's why thehplippackage is 30 MB of Python modules and support files, andhplip-guionly 2.2 MB of icons, metadata, and symlinks.@james
FTR, that perspective (the second one) was the drive behind my PR that started all this.
My thinking was: A user with an HP printer reads on a support site or forum that they can use the HPLIP tools to manage that printer. The software is said to provide things like an install/discovery tool, a scanning application, and a system-tray management and monitoring daemon.
So the user runs
sudo dnf install hplip. (What I didn't realize, at the time, is that the package is installed by default, so that command won't do anything except report "already installed".) Regardless, they've got HPLIP installed. And yet, they still have none of the things they're expecting to have. There's no discovery tool, no scanning interface... from the perspective of their desktop Applications grid, there's literally nothing. Someone who knows enough to dig into the package contents will find a whole bunch of new commands in/usr/bin/, but they're all low-level things likehp-testpage,hp-timedate,hp-query, etc. There is anhp-scan, but it has a complicated command-line interface.The user has to somehow divine that they need to
sudo dnf install hplip-gui, to get any of the things that are typically considered "the HPLIP tools". That doesn't seem very friendly.In the bugzilla bug I floated the idea of splitting the
hplippackage into anhplip-basesubpackage (containing the current contents ofhplip, and anhplip-guipackage (unchanged), with onlyhplip-baseinstalled by default. Then, thehplip(now meta-)package could pull in the-guisubpackage as well, when a user on a desktop system runssudo dnf install hplip.I had no expectation that my half-serious proposal would be accepted, as it seemed like more effort than it's worth to do. Instead, tho, it was vetoed as also unacceptable, which perplexes me. Completely independent (literally, as in have-no-dependency-relationships-to-the-main-package)
-guisubpackages seem to make it unnecessarily hard for users to install software with all of its functionality intact. At least, that's how it feels to me.If hplip pulls in applications with user-visible desktop files, then Fedora Workstation and other desktop spins won't want hplip installed by default anymore.
This sounds like the ideal solution, because it's nicer to keep the desktop files with their corresponding binaries. But the status quo is also acceptable. What's not acceptable is pulling in the desktop files by default.
I'm not sure this sentiment is really specific enough to codify into the packaging guidelines. :)
I'm really not sure what you're looking for. I could change "unless strictly required" to "unless it really makes sense to do so"? For example, any GNOME application with a help document is going to legitimately require Yelp. There's also the example of a video game level editor, or a plugin-in for any sort of application.