https://bugs.kde.org/show_bug.cgi?id=369232
Jarosław Staniek <stan...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stan...@kde.org
--- Comment #1 from Jarosław Staniek <stan...@kde.org> ---
I understand the desire for purity. But we had to choose something closer to
good deployment practices and implemented without stressing the packagers
though so the packagers are able to deliver *working* packages. The problem is:
Kexi is being packaged without the .rcc file as a runtime dependency leads to
deployment failure. Then users are confused that Kexi refuses to start.
It's hard to accept this approach in practice so I came up with the behaviour
as you explained. openSUSE package maintainer who collaborated with me on these
improvements was able to properly package the app and libs.
In the years of history it just happens that some packagers never actually run
the app, I don't even dream about them always running autotests (before
shipping). But in a pro world this is one of items on the check list.
If we have a way to ensure packager sets proper runtime dependencies, I'd
happily change the FATAL_ERROR to just a warning. For now warnings are pretty
much ignored by those deploying the software, and of course I am not surprised.
Requiring runtime dependencies at packaging time isn't something unusual if you
assume that before finalizing the process of building Kexi running autotests is
required (but still this cannot be forced because e.g. build systems lack
$DISPLAY). When tests are executed, the icons have to be accessible (and all
other runtime dependencies for that matter). This is why I am thinking there's
not much to fight for.
Those, in rare cases, who want to take responsibility of disabling the check
can patch the cmake script and then ensure ("by hand") that the runtime
requirements are in proper version. But let's realize that for example in the
KDb project in the future as we move on with features we would be checking
exact features of dependencies such as SQLite in exactly the same way: by
requiring the runtime deps at configure time. Some cmake's Find*.cmake actually
check the software by building and running apps at configure stage to really
know what features we have. So that's not a new thing.
Disclaimer: packagers are doing great work but just don't have the resources to
study internal of requirements in given software. App maintainer on the other
hand cannot accept software installation that are not working because of so
simple reason/mistake as described.
PS: it would be best if the check was exported as a cmake script in
breeze-icons.git.
--
You are receiving this mail because:
You are watching all bug changes.
