Should I open a bug or would I be wasting my time

[Duncan]

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.