On Fri, Feb 22, 2008 at 09:15:09AM -0500, James Carlson wrote: > Liane Praza writes: > > 2.1.4. S-Lang Library (dependency of mutt), version 2.1.3 > > > > http://www.jedsoft.org/slang/ > > > > S-Lang is a multi-platform programmer's library designed to allow > > a developer to create robust multi-platform software. > > Perhaps a dumb question: does mutt really need s-lang? It seems to > link against curses just fine, and it doesn't seem to use the > elaborate interpreter and environment that s-lang provides (though I > may have missed something). If mutt is somehow "better" when linked > against s-lang, ok, I guess that's a fine reason to use it, but > otherwise this seems to be a lot of baggage to drag in for mutt, and a > fairly good risk that we'll have multiple terminal control databases > and thus consistency problems.
I'm not sure that it is -- I get certain obnoxious errors when using mutt w/ S-Lang and certain TERM values, but I forget what they are. > > mutt, fetchmail, procmail, and s-lang are Open Source projects, > > and their design, development and release schedule are external to > > SMI. They make no explicit promises or guarantees of API or ABI > > compatibility between releases. > > They may not make promises, but we can. It's a risk/cost/benefit analysis. The executables' paths must be Committed. Options for MUAs that only interactive users would use could be Volatile, IMO, but options for things like procmail and fetchmail really need to be Uncommitted at worst (because scripts will depend on these). Etc... If the complexity of managing too fine-grained a set of commitments gets out of hand then just make it all Uncommitted and state that as a result we may eventually have to ship multiple versions and/or spend resources on backporting security patches (for example). > Please make at least fetchmail and procmail either Committed or (at > worst) Uncommitted. They're useless as Volatile, and given that many > of us have relied on these utilities for a decade or more without > seeing any incompatible changes, dubbing them "Volatile" merely > because the author doesn't draw an SMI paycheck seems wrong. I agree. Even if we ask non-Sun contributors to commit to supporting these things, if we (Sun) really want these utilities (IMO we should/do) then we'll be willing to provide the minimum level of required support should the original non-Sun OpenSolaris contributor go away. So just go with Uncommitted for the interfaces + Committed for the executable locations. Nico --
