Ken Causey <ken at kencausey.com> wrote:
> I've been running Debian for years so I'm aware of it. ;) 
And probably more so than I, I'm a relative newbie to this wonder.

> There are
> good examples of similar situations in Debian, logcheck being one of the
> better ones.  This situation however is solved in Debian (to the best of
> my knowledge) by the package being configurable from an init-style
> directory of files where every package that wants to make adjustments to
> the logcheck configuration creates a new file based on it's package
> name.  This removes the possibility of conflicts.  This doesn't map well
> to our situation where adding support to SB requires adding messages
> both to SB classes as well as classes of the package being linked to SB
> (in this case Jacaranda).  This would be analogous to Debian packages
> having to jointly modify a logcheck configuration file AND adjust their
> own configurations based on whether or not logcheck was installed.
I think our problem here is not (merely) that we need joint structures,
composed from different packages. These could be generated anew/fixes
after any change in the packages that affect it. The problem is that we
currently don't have this mechanism to capture package removals and
handle them properly.

I see two general directions - 
1. Make class responsible for handling these things by design. Example,
let SB have a registry of concerned classes. When SBMyApp is loaded, it
registers itself there, as well as adding it's class extensions. When it
is unloaded, it removes itself. When the list changes, all the other
members are notified. Note this approach puts the onus (and the
flexibility) in the application itself. This is similar to having Debian
packages that (for example) run a utility regenerating the logcheck
config after being installed (I think this is similar to the way kernel
modules are handled in Debian - the combined file modules.conf is
generated).
2. Make whatever structures we create for handling depedencies be
involved in maintaining the dependency constraints. When a prereq is
about to be removed, it would let the user know that it's users will be
removed, too, and then unload in the correct order. This might also
activate fixed callbacks in the affected packages, allowing them to
adjust.
 
> Yes, this is not a pressing issue and I'll be looking forward to how
> things compress.  I was primarily trying to figure out what to do with
> SBJacaranda in the immediate term but then mixed it with speculation
> about long term plans.  If this issue has already been considered or is
> on the plate to be considered, that's great.

I'd tentatively advise not to invest too much thought/work in the
current state, since things will change (note the value-neutral
statement ;-), but documenting whatever needs to be done for
installation to work in the package's SM entry can save the users most
of the trouble.

Daniel