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