Claus Reinke wrote:
a few examples, of the top of my head:
- consider the base split in reverse: if functionality is only repackaged,
the merged base would also provide for the previously separate
sub-package apis (that suggests a separate 'provides:' field,
though, as merely listing version numbers wouldn't be sufficient)
- consider the base split itself: if there was a way for the base split
authors to tell cabal that the collection of smaller packages can
provide for clients of the the old big base, those clients would
not run into trouble when the old big base is removed
These two cases could be solved by re-exports, no extra mechanism is required.
- consider adding a new monad transformer to a monad transformer
library, or a new regex variant to a regex library - surely the new
package version can still provide for clients of the old version
This case doesn't work - if you add *anything* to a library, I can write a
module that can tell the difference. So whether your new version is
compatible in practice depends on the client.
- consider various packages providing different implementations
of an api, say edison's - surely any of the implementations will
do for clients who depend only on the api, not on specifics
Yes, and in this case we should have another package that just re-exports
one of the underlying packages.
You seem to want to add another layer of granularity in addition to
packages, and I think that would be unnecessary complexity.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
