LCDproc development and user support list

Text archives Help


[Lcdproc] Why modules


Chronological Thread 
  • From: joris AT robijn.net (Joris Robijn)
  • Subject: [Lcdproc] Why modules
  • Date: Thu Aug 14 18:53:01 2003

On 14 Aug 2003 at 9:59, Thomas Runge wrote:

> I know, I'm opening a can of worms here, but why does lcdproc has
> dynamically loadable drivers? Aren't we OpenSource? When a new
> driver gets implemented, I can just rebuild from source or get
> a new binary package which probably pops up earlier than just
> the driver object file.

The big advantage of loadable modules is in packaging. In a binary distro
you can package all modules for all drivers. This does not require
dependencies to libs.

Example: you install package LCDproc 0.5 (which does not yet exist),
which comes with all driver modules (in compiled form), including lirc
(an infrared input driver).
However, you do not have liblirc installed. This is no problem while you
do not load the lirc module. Only when you try to load the lirc driver
this will fail.

With drivers compiled in this would be a problem. We should need to
exclude lirc from the standard package. Or we should need to have a
dependency to liblirc (grrr). Now there's also svgalib, curses, irman...

The security risc is the same as for any other lib (and there are quite a
lot of them already :)

(We have seen in the previous mail, that this even confuses users.)

Yes, if they use a new version of LCDproc and stubbornly try to use an
old config file. They HAVE received the new config file as part of the
source package, it's probably not packaged for nothing.

Joris
--
Joris Robijn
<joris AT robijn.net>
Mobile: 06 288 41 964

// To understand recursion, we must first understand
recursion





Archive powered by MHonArc 2.6.18.

Top of page