2008/5/25 Peter Tribble <[EMAIL PROTECTED]>: > On Sat, May 24, 2008 at 1:18 AM, Stephen Hahn <[EMAIL PROTECTED]> wrote: >> >> 16. Substitution and virtual packages. A number of messages have >> wondered about making many components interchangeable behind a >> virtual package. The classic example is sendmail/postfix/ >> favourite MTA. My concern is that there's a great deal of cost in >> making a key component node "substitutable" in this sense. I am >> nervous about designing centrally about what I think is actually a >> very limited and complex class of components. I guess I'll let >> this topic run... > > In most cases, though, the semantic is not a generic "member of class > foo", but "one of the following". As examples: > > An app knows it can send mail messages, using /usr/lib/sendmail. So > it can specify "sendmail OR postfix". (Maybe others - but not all > MTAs can be called like sendmail.)
One of the early conversations, if I remember correctly, was being able to express that you depend on /usr/lib/sendmail. As long as a package delivered that, it "met" your dependency. > An app integrates with the MTA (maybe a virus scanner). The package > can configure itself into postfix or qmail. So "something providing > smtp" isn't valuable, you again have to install one of the specific > MTAs (and possibly specific versions of those MTAs) or it won't > know what to do with it. > > Another common case is a database. Again, most applications > really specify "mysql OR postgres" - any old database simply > won't do. I've been arguing the very same thing. I am not convinced that generic dependencies actually work. Of course, to the packaging system, I don't think it matters. But as a policy for package creation, I think it isn't quite sane to have generic dependencies such as "database." I really do believe that, in general, it is exactly as you put it: "X or Y", not "*". -- Shawn Walker "To err is human -- and to blame it on a computer is even more so." - Robert Orben _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
