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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux