[Haskell-cafe] Hackage policy question

Wolfgang Jeltsch g9ks157k at acme.softbase.org
Wed Sep 10 06:48:35 EDT 2008

Am Mittwoch, 10. September 2008 11:47 schrieben Sie:
> On Wed, 2008-09-10 at 10:11 +0200, Wolfgang Jeltsch wrote:
> > Am Mittwoch, 10. September 2008 00:59 schrieb Duncan Coutts:
> > > […]
> > >
> > > The .tar.gz packages are pristine and must not change, however
> > > the .cabal file that is kept in the hackage index could change and that
> > > information will be reflected both in the hackage website and just as
> > > importantly for tools like cabal-install.
> >
> > I don’t think this is a good idea.  The package description, list of
> > exposed modules, etc. belongs to the software, in my opinion.  So
> > changing it means changing the software which should be reflected by a
> > version number increase.
> Remember that all the distributors are doing this all the time and it
> doesn't cause (many) problems. They change the meta-data from what the
> upstream authors give and they add patches etc etc.
> Granted, they do use a revision number to track this normally.

And this is an important difference, in my opinion.  Changing meta-data is 
probably okay if a revision number is changed.

> […]

> The most radical thing is tightening or relaxing the version constraints on
> dependencies. For example if your package depends on foo >= 1.0 && < 1.1 but
> then foo-1.1 comes out and although it does contain api changes and had the
> potential to break your package (which is why you put the conservative upper
> bound) it turns out that you were not using the bits of the api that changed
> and it does in fact work with 1.1 so you can adjust the dependencies to foo
> >= 1.0 && < 1.2.

But what happens if you need the loose dependencies.  cabal-install checks the 
updated Cabal file and might see that you’ve already installed the correct 
dependencies.  It downloads and unpacks the package and then Cabal uses the 
Cabal file included in the package and complains about unmet dependencies.  
Or shall there be a mechanism to overwrite the package’s Cabal file with the 
updated Cabal file?

> […]

> So we should think about how to make it less confusing. Perhaps like
> distributors use an extra revision number we should do the same.

Yes, maybe this is the way to go.

> […]

Best wishes,

More information about the Haskell-Cafe mailing list