[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,
Wolfgang
More information about the Haskell-Cafe
mailing list