[csw-maintainers] Packages that require either package A or package B'

Ben Walton bwalton at opencsw.org
Thu May 21 20:27:54 CEST 2009


Excerpts from Philip Brown's message of Thu May 21 14:18:25 -0400 2009:
> Sounds like there isnt much reason to hack that kind of
> "multiple|optional dependancy' into the pkg delivery system then.
> We could accomplish basically the same thing by other means.

No, it can be handled above the actual package level by the tools
manipulating them (which was the gist of option c)...I do agree that
it's likely wasted effort to bolt it on at this point, since Sun will
be abandoning svr4 at some point in the not too distant future...

> To take the database dependancy specifically; I'm thinking some kind
> of generic database wrapper tool package.  Kinda like CPAN::DB, but
> for shellscripts :-) Then packages could depend on CSWdbwrapper, and
> use the appropriate tools in there as needed.

To be fair, perl is likely a better tool for this anyway, so the DB
module is a good choice. :)

> Not only does it solve the "problem" in that area, but it would solve it
> BETTER than how debian 'solves' it.

...except for the hole that is: none of those packages depend on the
actual db package, so removing it wouldn't generate any warnings
(unless some other package marked it explicitly).  Would the
CSWdbwrapper depend on both?  With debian, removing the package
providing the 'generic' rdbms would alert you to the dependency
breakage.

> How does that sound?

Given the workings of svr4 packages, about as good as it'll get, most
likely.

-Ben
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20090521/0434153a/attachment-0001.asc>


More information about the maintainers mailing list