[arch-general] Consolekit etc. stubs? (Was: My end-user $0.02 on /etc/rc.conf splitting.)

[Scott Lawrence]

On Sun, 22 Jul 2012, Fons Adriaensen wrote:

>> What do you expect the maintainer of these packages to do anyway? In
>> order to provide useful packages for the majority of people they have to
>> pull this things in, there is just no way around it.
>
> Yes there is. Take again the xdm example. Why do we have dynamic
> libs ? There is really nothing to stop the xdm developer to write
> his code such that it will use consolekit *if it is installed* and
> do without it otherwise. It doesn't have to be a dependency, that
> is just bad design. And anyway, if a login has to be declared as
> a consolekit session that could as well be done outside xdm. This
> sort of thing shoulnd't be hardcoded into binaries.

A little OT (hence changed subject), but I've sometimes wondered - shouldn't 
it be possible to create a "stub" version of libdbus, libconsolekit, et al 
that does nothing but the least necessary to get the calling program working 
correctly? With dynamic linking, such libraries would be installed in place of 
those bloated messes and result in a nicely-running system even for programs 
that have hard-coded dependencies on dbus and the rest?

It's admittedly not the cleanest solution (better to remove those dependencies 
altogether), but I think it would be a pretty useful hack to "back-port" such 
software to cleaner systems.

Is there a good technical reason why this is impossible or impractical?

-- 
Scott Lawrence

Linux jagadai 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 GNU/Linux