-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
Unwrap Qt 5 packages #26336
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
Unwrap Qt 5 packages #26336
Conversation
Could you refer to examples? Can |
MaintainabilityWhenever an old package gets a new dependency, I have to go through the whole dependency graph and prune the InteroperabilityIn another branch, I am packaging the KDE PIM suite (KMail, KOrganizer, Kontact, etc.). All the KDE packages are designed to detect optional runtime dependencies, but the PIM suite takes this to an extreme. With the wrappers, we either need to package the PIM suite as one monolith or tolerate large duplicate symlink farms for each package. I don't like the monolith approach because it requires that we fight upstream's design for their software. It is designed to be installed into an environment and cooperate with other packages in that environment, and I don't like subverting that goal. Also, I imagine many users do not need or want the entire PIM suite; for example, they may only use KMail and do not want to install gigabytes of unrelated software. We had a solution in
|
Thanks for the explanation @ttuegel. We should indeed not fight upstream's design. I thought it be good to have the argumentation you gave now because its otherwise hard to track why certain design choices were made and abandoned. |
We can then eliminate any occurrence of qt?Wrappers?
2017-06-03 12:39 GMT-03:00 Frederik Rietdijk <notifications@github.com>:
… Thanks for the explanation @ttuegel <https://github.com/ttuegel>. We
should indeed not fight upstream's design. I thought it be good to have the
argumentation you gave now because its otherwise hard to track why certain
design choices were made and abandoned.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#26336 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFrc9iFRWY5dhFviCAbndeT_J-IK4PtRks5sAX5LgaJpZM4Nu4D2>
.
|
What does that mean exactly? Some apps must be launched through a .desktop file? Simply typing the command name in a shell wont work? |
It means that |
Thanks for the clarification. That doesn't sound too bad. As a non-desktop-suite user I got a bit worried there for a second :) A bit off topic, but just in case these changes make it simpler/possible to fix the icon issue in kde apps installed/run as standalone apps: Okular5 for instance works when installed standalone (lots of icons missing, but not that big a deal actually). BUT - startup time is affected due to how icon lookup works: okular makes 400k+ stat calls looking for icons. This seems to be because |
doc/languages-frameworks/qt.xml
Outdated
|
||
</section> | ||
|
||
<section xml:id="ssec-qt-kde"><title>KDE</title> | ||
|
||
<para>The KDE Frameworks are a set of libraries for Qt 5 which form the basis of the Plasma desktop environment and the KDE Applications suite. Packaging a Frameworks-based library does not require any steps beyond those described above for general Qt-based libraries. Frameworks-based applications should not use <literal>makeQtWrapper</literal>; instead, use <literal>kdeWrapper</literal> to create the necessary wrappers: <literal>kdeWrapper { unwrapped = <replaceable>expr</replaceable>; targets = <replaceable>exes</replaceable>; }</literal>, where <replaceable>expr</replaceable> is the un-wrapped package expression and <replaceable>exes</replaceable> is a list of strings giving the relative paths to programs in the package which should be wrapped.</para> | ||
<para>The KDE Frameworks are a set of libraries for Qt 5 which form the basis of the Plasma desktop environment and the KDE Applications suite. Packaging a Frameworks-based package does not require any steps beyond those described above for general Qt-based packages.</para> |
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.
The manual should also mention, that the result of nix-build
cannot be directly called
and suggest that nix-shell -p <command>
can be used as an alternative.
10cc10e
to
ae4a628
Compare
Using a distinct prefix for plugins and QML libraries allows multiple Qt 5 minor versions to coexist in the same environment.
QStringLiteral stores strings in UTF-16 format, preventing Nix from detecting dependencies.
It is no longer necessary to wrap Qt packages
Plugin and QML import paths were previously determined by NIX_PROFILES. Using PATH instead allows Qt applications to work under nix-shell without further modification.
Plugin and QML import paths were previously determined by NIX_PROFILES. Using PATH instead allows Qt applications to work under nix-shell without further modification.
This seem to have been broken in NixOS#26336.
ultrastar-creator fixed in 558b5fb |
@Mic92 ultrastar-manager still has references to |
@Mic92 Awesome, you rock! |
Any immediate ideas about this seemingly non-sensical error of kdiff3? http://hydra.nixos.org/build/55590912
Bisection on staging narrowed-down the range into this PR's commits; bad: fc72335, good: 6beea32. Interestingly, it does build on master. There's also a similar error for kdevplatform: http://hydra.nixos.org/build/55596900 |
@vcunat I've been adding the missing dependencies to the packages. Maybe some dependencies were not propagated anymore. |
Thanks, the related problems I know are fixed on master, after 43ca911 and a couple preceding commits. |
Motivation
The Qt 5 wrappers are difficult to maintain and prevent runtime interoperability between packages. The latter is an important goal for desktop environments such as KDE. Fortunately, the wrappers are also unnecessary.
This pull request removes
makeQtWrapper
andkdeWrapper
. Instead of wrapping programs, required runtime dependencies are propagated throughpropagatedUserEnvPkgs
. However, this does mean that some applications may not work correctly if invoked directly from the Nix store. This necessitates other changes, most notably: Qt plugins are now installed in a different prefix for each minor version to prevent conflicts.Testing
(nix.useSandbox on NixOS,
or option
build-use-sandbox
innix.conf
on non-NixOS)
nix-shell -p nox --run "nox-review wip"
./result/bin/
)I have also run the relevant NixOS tests.