Dependencies

[David Zeuthen]

On Mon, 2006-10-09 at 10:30 -0500, Jerry Haltom wrote: 
> > CUPS should then use HAL to obtain the list of printers, and be updated
> > when new ones are inserted/removed.

We've been doing this in Fedora for a while. See the hal-cups-utils
package in Fedora Core for details. It runs programs on printer add /
removal to configure Cups (adding / removing print queues I think) -
invoked by HAL... with the device "address" in the environment...

> I think this is an important point to make in the minds of people
> thinking about Upstart. Does Upstart attempt to solve these problems for
> us? I don't think so. I think Cups, and other similar software, still
> needs to be updated to auto detect/scan hardware, and I don't think
> Upstart automatically provides this. Upstart does however make
> bootstrapping Cups itself easier. It can make sure Cups is running when
> any printer hardware is altered. Cups can't do that itself, because it's
> not yet running. Hence the current situation with cups running whether
> there is a printer or not.

IIRC, today you also need Cups to be running if you want it to detect
networked printers. 

I guess my view of the whole thing.. dependencies in particular... comes
down to the fact that adding support for dependencies somewhat hides the
problem of fixing things such as Cups. Sure, it's great we can start
Cups when a printer is attached... but ideally Cups itself would only
run when actual printing services are needed. 

(and we'd use something more modern like mDNS / Avahi to discover
printers from the desktop session so Cups don't need to be running for
this simple task.)

One way to do this is to use D-Bus activation (though this is not yet
available on the system message bus), e.g. when you call into the name
org.Cups.Printing or whatever... the cups daemon is launched to handle
the incoming request... when it's done servicing you... it may exit
again (standard feature of IPC systems that support activation).

As a data point at least launchd seems to follow this design, I was just
looking at http://developer.apple.com/macosx/launchd.html and it says

        "Many services are configured using StartupItems for historical
        reasons. Some, however, are run this way because they have
        interdependencies. These jobs cannot be directly translated to
        run under launchd, which does not provide for explicit
        dependencies. Instead, services are supposed to wait for needed
        resources to become available, which handles the majority of
        cases cleanly."  

Of course there are always corner cases and, eh, it's a huge task to
clean up the existing horde of UNIX daemons.

     David