Marek Kochanowicz posted on Sat, 30 Mar 2013 20:04:42 +0100 as excerpted:
> On sobota, 30 marca 2013 19:28:40 CEST, Kevin Chadwick wrote:
>> Considering my last mail on the subject got zero response except from
>> one very helpful someone who has removed polkit by using gentoo,
>> perhaps because it invited too much discussion.
>>
>> Would I be wasting my time If I opened a bug as to why you can disable
>> polkit with the whole of KDE working just fine and yet if you try to
>> remove it you have to remove the whole of kde including k3b which I
>> have never had to use sudo with in the past. nvidia-settings has an
>> apparently hard dependency on polkit, which is obviously a bug.
>>
>> Is it KDE's position that these dependencies (ignoring nvidia-settings)
>> in ubuntu and debian are bugs?
>
> Not KDE bugs. This is ubuntu/debian decission.
Correct.
Based on gentoo's kdelibs (a core dependency for anything else kde)
package dependencies, there's a pre-build-configure-time option
(apparently --with-PolkitQt-1 to turn it on, --without... to turn it off)
for kdelibs itself.
If that is turned on, then kdelibs both supports and symbol-links to the
polkit-qt package, which in turn symbol-links to polkit itself. As with
most library linking, lack of availability of that symbol-linked library
at runtime to provide those symbols... will almost certainly result in a
crashing (often before it even fully initializes) executable.
Kdelibs can be built with our without support for polkit, but if it's
build with it, polkit must be there in ordered to run anything using
those bits of kdelibs (which most kde apps will), or the executables will
have missing symbols and will not run at all.
That's how such pre-build-time-configure options normally work, anyway,
for dependencies that must be there (if the option is enabled) both at
build and runtime.
For dependencies that aren't that actually linked in, only required at
build-time (like cmake, for most kde apps, or gcc or another compiler
itself), there's a different kind of dependency, as there is for those
only required at runtime (perhaps because an executable is invoked,
instead of a library linked against, udisks and upower are this sort of
dependency for kdelibs).
Which of course is one of the cases gentooers make for gentoo's built-by-
the-end-user system, thus exposing exactly this sort of choices to the
end-user: many options must be enabled/disabled at build-time, if they
are to be supported at all, and once they're enabled for the build, they
must be there at runtime as well, or the app simply won't run at all. A
binary-based distro thus by definition must choose which of these sorts
of options they're going to support at build-time, and for anything they
turn on, all users of that distro, whether they actually use that feature
or not, will have to have the libraries to support it installed, or the
app simpy won't run at all.
Since in general a feature is likely to be useful to someone somewhere,
most distros tend to error on the side of including support for nearly
everything -- far more than an individual user is likely to use -- simply
because *SOME* of their users will find the feature useful. This results
in vastly over-bloated systems, slowing down both load-time and runtime
in ordered to support features few users actually use, but enough people
do use that it's considered useful to have the features enabled, even tho
it costs the majority speed and install-space for stuff they're not going
to use.
Of course there's security implications to that as well, since all those
otherwise unused libs are now that much a broader target for
vulnerabilities, etc.
Gentoo (and other similar end-user-configured-and-built) exposes those
choices to the person actually doing the build and install, who can then
build as slim or full-featured a system as they wish. And the fact that
over time as updates come in, every installed package including those not
in active use must be built and rebuilt again and again, tends to
eventually STRONGLY encourage gentooers to only enable what they actually
need and use, disabling and uninstalling what they don't need and use, so
it doesn't need rebuilt again and again as the updates come in. For a
project as huge as kde is, that updates as frequently as kde does
(monthly updates, twice a month during the pre-release cycle for those
like me who choose to install and run them), those repeated rebuilds
become an extremely compelling argument to slim down the installation as
much as possible, and I've done just that, here.
So indeed, for those running debian/ubuntu, polkit support is a debian/
ubuntu decision. But by the nature of things, they must make that
decision for all those using their binary packages at once, at build-
time. And again by the nature of things, that means most binary-based
distros vastly overbuild, enabling options to support a few users that
the majority wouldn't necessarily need or use at all -- they're simply
along for the ride given that the choice must be made once for everybody
that's going to be using those binary packages.
That's a tradeoff most users appear to be willing to make, however, since
binary-based distros users unarguably vastly outnumber source-based distro
users, despite the clear advantages in terms of end-user-exposed control
the latter have, at the expense of time-to-build and complexity to manage
all those choices, even if it /is/ all very automated, such that once the
choices are made, updates generally "just work" and take little more
actual admin time than they would on a binary distro, since the build
itself doesn't require the admin's attention at all.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
