-
-
Notifications
You must be signed in to change notification settings - Fork 14.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
qutebrowser-qt5: replace qt5.qutebrowser #251671
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This package is already named qutebrowser
.
We already have a package named qutebrowser-qt6
.
There is no need to pollute top-level/all-packages.nix
with yet-more decorated package names. Prior to #250171 we were automatically detecting and using the newest available version of QT for the qutebrowser
package. That's the right way to do it.
We were? Afaict we were simply using Qt5 by default. |
While I agree that it's annoying some people would have to replace |
Agreed, and that's why qutebrowser-qt6 should be removed as well, it should not have been introduced in the first place. Unfortunately the upgrade to Qt6 took so long that people got impatient... |
If we care about not polluting the top-level we do have the option of nesting the qt5 variant inside the top-level derivation attribute somewhere, although I'm not sure if there is any precedent for that elsewhere. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general this looks good to me, but I think this kinda of change (defaulting to Qt6 instead Qt5) should have a entry in release notes.
68e0d3c
to
67cd0f1
Compare
The qutebrowser maintainers agree that the Qt 6 version should be the default.
Then why was my review deleted with "The qutebrowser maintainers agree that the Qt 6 version should be the default." as the justification? |
Which is worse, a top-level attr or a non qt package in the qt5 set |
We have plenty of packages besides python in the pythonPackages set. Indeed, the difference between |
Python programs are not supposed to be in pythonPackages, only modules. |
inherit (__splicedPackages.qt6Packages) qtbase qtwebengine wrapQtAppsHook qtwayland; | ||
}; | ||
|
||
qutebrowser-qt5 = callPackage ../applications/networking/browsers/qutebrowser { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It needs to have -qt5 appended to the pname
pname = "qutebrowser"; |
Because nix-env uses name
, idk what it does when 2 derivations have the same pname and version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I honestly don't care, nix-env
shouldn't be used. This might be fixed by marking the Qt 5 version insecure though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added it
@amjoseph-nixpkgs I don't think there's anything here (functionally) that you should be against since it's just moving the attr. We have done -X suffixed attrs before too, though usually they're done via a callPackage arguments. |
Can you imagine how bonkers it would be if every package that depended on python had three top-level variations?
... and people had to deal with the version that works for them being renamed from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should mark qt6Packages.qtbase
as meta.broken
if stdenv.buildPlatform != stdenv.hostPlatform
.
inherit (__splicedPackages.qt6Packages) qtbase qtwebengine wrapQtAppsHook qtwayland; | ||
}; | ||
|
||
qutebrowser-qt5 = callPackage ../applications/networking/browsers/qutebrowser { | ||
inherit (__splicedPackages.libsForQt5) qtbase qtwebengine wrapQtAppsHook qtwayland; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
inherit (__splicedPackages.qt6Packages) qtbase qtwebengine wrapQtAppsHook qtwayland; | |
}; | |
qutebrowser-qt5 = callPackage ../applications/networking/browsers/qutebrowser { | |
inherit (__splicedPackages.libsForQt5) qtbase qtwebengine wrapQtAppsHook qtwayland; | |
inherit (if stdenv.buildPlatform == stdenv.hostPlatform then __splicedPackages.qt6Packages else __splicedPackages.libsForQt5) | |
qtbase qtwebengine wrapQtAppsHook qtwayland; | |
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should make it intransparent to the user that they're using a different Qt version when cross-compiling.
That can be done in a separate PR. |
It would be. That's why you have to use |
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/qt5-packages.nix and https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/qt6-packages.nix seems to be the places for packages like this? |
No, that's for Qt libraries. |
@Artturin Do you think this can be merged? |
7315c63
to
7adf62e
Compare
Applications don't belong in the qt5 scope.
7adf62e
to
4bd758c
Compare
It seems to be working normally, though I noticed this warning:
|
Successfully created backport PR for |
So... is the "QtWebEngine version mismatch" warning not important? |
IDK, it was happening before so /shrug. |
Minor eval failure fix around |
Description of changes
see #251660
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)