On Tue, 2003-01-21 at 15:28, Daniel Vainsencher wrote:
> Hi Ken.
> 
> (for some reason, I'm getting all your mails twice. Could you please
> look into that?)
> 

Answered in another messages sent directly to Daniel.

> Your question is really not about SB specifically, it's about how
> packages with multiple dependencies are managed. And I'll split it in
> two -
> * How should we package such code?
> * How do we make the system smart enough to handle these dependencies
> correctly?
> 
> First, as you're quite aware, nothing is yet complete that provides a
> complete solution to this problem. Second, if you want a pointer to one
> of Goran's inspirations when thinking of these issues (and mine too),
> see www.debian.org. This is a linux distribution that's actually a
> distributed project, handling >8000 packages on 11 architectures, that's
> solved such problems as depedencies, libraries, multiple versions,
> replacement of kernels.... it's a different situation, but we've
> certainly alot to learn from it.
> 

I've been running Debian for years so I'm aware of it. ;)  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.

> Now to your questions. Goran will probably answer soon, explaining about
> SM1.1, which should add package versions. These and some other
> enhancements should allow us to implement various tools on top of the SM
> catalog, including tools that deal with dependencies. Some ideas about
> how these should work have already been proposed, and I'm sure we'll see
> some nice solutions come up after 1.1 is out.

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.

Ken