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?

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?

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.

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).

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.

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?

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:

Packages MUST NOT depend on desktop applications unless strictly required. In particular, packages SHOULD NOT have a Requires or Recommends dependency on any package containing a visible desktop file (a .desktop file that does not contain the line NoDisplay=true) , directly or indirectly, unless the dependency is strictly necessary. Packages that contain a visible desktop file SHOULD NOT have a Supplements dependency on any other package.

@decathorpe

Speaking for myself, I found it very Windows-esque that suddenly some weird HP software got installed on my machine.

See, that's the funny thing about this --- the weird HP software was already installed on your machine.

This came about because hplip started (at my request) Recommending its own GUI subpackage (conditionally, if the Qt gui package is also installed)... which caused hplip-gui to be newly pulled in on systems with hplip already installed. Which is most of them, because hplip is 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'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:

Packages MUST NOT depend on desktop applications unless strictly required. In particular, packages SHOULD NOT have a Requires or Recommends dependency on any package containing a visible desktop file (a .desktop file that does not contain the line NoDisplay=true) , directly or indirectly, unless the dependency is strictly necessary. Packages that contain a visible desktop file SHOULD NOT have a Supplements dependency on any other package.

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".)

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.

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).

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.

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 ...

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:

1. GUI icons used in the HPLIP graphical tools
2. Two .desktop files for those graphical tools
3. Symlinks from /usr/bin/ to the various /usr/share/hplip/ Python modules that implement those tools

The tools themselves — graphical and console based alike — are all installed in /usr/share/hplip/ by the hplip package. It's only the GUI components' visibility to the user that gets wired up by hplip-gui. That's why the hplip package is 30 MB of Python modules and support files, and hplip-gui only 2.2 MB of icons, metadata, and symlinks.

@james

"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).

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 like hp-testpage, hp-timedate, hp-query, etc. There is an hp-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 hplip package into an hplip-base subpackage (containing the current contents of hplip, and an hplip-gui package (unchanged), with only hplip-base installed by default. Then, the hplip (now meta-)package could pull in the -gui subpackage as well, when a user on a desktop system runs sudo 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) -gui subpackages 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.

In the bugzilla bug I floated the idea of splitting the hplip package into an hplip-base subpackage (containing the current contents of hplip, and an hplip-gui package (unchanged), with only hplip-base installed by default. Then, the hplip (now meta-)package could pull in the -gui subpackage as well, when a user on a desktop system runs sudo dnf install hplip.

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.

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."

I'm not sure this sentiment is really specific enough to codify into the packaging guidelines. :)

...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'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.