Proposal: Ignore sub-minor version components in package id

[Duncan Coutts]

On Tue, 2011-11-08 at 15:39 +0100, Joachim Breitner wrote:

> > We need (in future) to be able to distinguish different packages that
> > share the same ABI. So what needs to happen is that we include the ABI
> > as a separate field in the package db. That abi need not contain the
> > version number at all, it can be just some abi hash.
> > 
> > Then whether the dependencies should then use an installed package id or
> > a package abi is an interesting question. I think the right thing is to
> > use installed package ids. Just because it would be possible to update a
> > dependency to use the latest-ABI compatible version doesn't mean that it
> > should be immediate and automatic. Indeed it would prevent us from
> > having a persistent package database, as adding new packages would
> > change the meaning of existing packages. Switching to a later
> > ABI-compatible version of a dependency should be a deliberate act. Hence
> > we should use installed package ids for dependencies.
> 
> thanks for your feedback. I’m not sure how your approach helps with my
> aim, which is: I want to be able to upgrade dependencies without having
> to recompile depending packages, unless the ABI changes.
> 
> If the depends field of an installed package refers to the package id,
> then either I have to rebuild the package; or a new operation “use newer
> package with the same ABI” needs to be introduced, which would change
> the depends field of an installed package to a new id, under the
> provision that the ABI is the same. Is that what you are hinting at?

Yes exactly. The latter, an explicit "switch dependency" operation. Of
course that operation might be performed automatically by some higher
level tool like cabal, according to some policy. But at the level of
mechanism (ie ghc-pkg db) it should be an explicit thing.

Of course in the bright future world of persistent package management
that'd really involve making a new installed package instance with the
new dependency but sharing the same installed files... :-)

Duncan