Hackage policy question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Hackage policy question

Iavor Diatchki
Hi,
I just noticed that hackage has introduced a new policy to disallow
changes to a package without bumping the version.  I understand that
this is probably a good idea for changes to the source code, but it
really would be nice to have a backdoor that allows for other changes.
 For example, I just uploaded a package, and realized that I forgot to
add a home-page entry in the cabal file.  I do not plan to increase
the version number of my application, only so that I can upload a new
version (the source code has not changed after all!).  I can imagine
similar problems related to fixing typos in the description, and other
fixes to the meta-data.

So, could we please revert to the old policy? (if we really want to be
fancy, the hackage upload script could check that the source code, and
other fields, such as LICENSE have not changed, as these should really
bump the version... in the mean time though, I think just being
responsible members of the community would work just as well!).

-Iavor
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Duncan Coutts
On Mon, 2008-09-08 at 16:26 -0700, Iavor Diatchki wrote:

> Hi,
> I just noticed that hackage has introduced a new policy to disallow
> changes to a package without bumping the version.  I understand that
> this is probably a good idea for changes to the source code, but it
> really would be nice to have a backdoor that allows for other changes.
>  For example, I just uploaded a package, and realized that I forgot to
> add a home-page entry in the cabal file.  I do not plan to increase
> the version number of my application, only so that I can upload a new
> version (the source code has not changed after all!).  I can imagine
> similar problems related to fixing typos in the description, and other
> fixes to the meta-data.

Yes. We've thought about this a bit. I'll tell you how I think it should
be managed, though I accept not everyone agrees with me.

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. So not only could the
maintainer fix urls or whatever but also adjust dependencies in the
light of test results. Consider the analogy to pristine tarballs and
debian or gentoo meta-data files. The former never changes for a
particular version, but the meta-data can be adjusted as the
distributors see fit.

The difference here is that those two would be in the same format,
the .cabal file inside the tarball that never changes and the one in the
index which may do. This is also the objection that some people have,
that it would be confusing to have the two versions, especially that
unpacking the tarball gives the old unmodified version.

> So, could we please revert to the old policy?

No :-) But I hope with the above system that will not be necessary. I
hope to implement this feature in the new hackage server implementation
that I'll be announcing shortly.

Really it's essential that the md5sums of tarballs never change. Untold
chaos results if they are allowed to change. For one thing our urls
become unusable for distro systems like gentoo, fedora etc and they
would have to take snapshots and keep their own pristine mirrors rather
than using our url as the canonical reference (obviously they do their
own mirroring too but they usually refer back to a canonical source).
That would be a huge pain for them and a barrier to our acceptance into
distros.

> (if we really want to be fancy, the hackage upload script could check
> that the source code, and other fields, such as LICENSE have not
> changed, as these should really bump the version... in the mean time
> though, I think just being responsible members of the community would
> work just as well!).

Indeed we'll also have to check things carefully if we allow package or
distribution maintainers to adjust the .cabal files in the index. For
example changing exposed modules or the name or version number is right
out. We'll err on the restrictive side and gradually loosen as we decide
it's safe and acceptable.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Wolfgang Jeltsch-2
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.

Why can’t package maintainers double-check that they got everything in the
Cabal file right before the package is uploaded to Hackage?  And if one has
forgotten a URL or something like that, it is still possible to release a new
version where just the 4th component of the version number was changed which
means precisely that the interface didn’t change.

> […]

> The difference here is that those two would be in the same format,
> the .cabal file inside the tarball that never changes and the one in the
> index which may do. This is also the objection that some people have,
> that it would be confusing to have the two versions, especially that
> unpacking the tarball gives the old unmodified version.

Yes, it *is* confusing.

> […]

> I hope to implement this feature in the new hackage server implementation
> that I'll be announcing shortly.

May I kindly ask you to *not* implement this feature?

> […]

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Ross Paterson
In reply to this post by Duncan Coutts
On Tue, Sep 09, 2008 at 10:59:17PM +0000, Duncan Coutts wrote:
> 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. So not only could the
> maintainer fix urls or whatever but also adjust dependencies in the
> light of test results. Consider the analogy to pristine tarballs and
> debian or gentoo meta-data files. The former never changes for a
> particular version, but the meta-data can be adjusted as the
> distributors see fit.

So if Debian or Gentoo etc repackage one of these packages in their
distributions, what is the pristine tarball that they use?
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Duncan Coutts
In reply to this post by Wolfgang Jeltsch-2
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. For
example a package foo-1.0 on hackage would become
dev-haskell/foo-1.0.ebuild in gentoo and if it needs to be updated for
some reason it becomes dev-haskell/foo-1.0-r1.ebuild and the number is
increased by one for every subsequent revision. Distros like debian have
similar systems.

> Why can’t package maintainers double-check that they got everything in the
> Cabal file right before the package is uploaded to Hackage?  And if one has
> forgotten a URL or something like that, it is still possible to release a new
> version where just the 4th component of the version number was changed which
> means precisely that the interface didn’t change.

Note that the distros are actually making code changes (applying bug fix
patches) and not bumping the upstream version number, though they do
bump their additional revision number. I'm not suggesting anything so
radical. I'm just suggesting that you could change the category tags, or
improve the description. 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.  Again, this is just the sort of thing that distros do.

> > […]
>
> > The difference here is that those two would be in the same format,
> > the .cabal file inside the tarball that never changes and the one in the
> > index which may do. This is also the objection that some people have,
> > that it would be confusing to have the two versions, especially that
> > unpacking the tarball gives the old unmodified version.
>
> Yes, it *is* confusing.
>
> > […]
>
> > I hope to implement this feature in the new hackage server implementation
> > that I'll be announcing shortly.
>
> May I kindly ask you to *not* implement this feature?

Well we need something like it I think. At least if we want to be able
to install things direct from hackage and have some level of reliance on
stated dependencies reflecting reality. It also allows us to share some
QA between all the distros which have to do this work anyway.

If we consider hackage as a raw upstream package collection that gets
picked over and QA'd by the distros then it's not necessary. But I think
we want to use it for both, for pristine upstream tarball releases but
also I think we expect to be able to use it directly with things like
cabal-install and so adding some distro-like management features is
useful.

So we should think about how to make it less confusing. Perhaps like
distributors use an extra revision number we should do the same. I had
hoped that would not be necessary but that's probably not realistic.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Duncan Coutts
In reply to this post by Ross Paterson
On Wed, 2008-09-10 at 10:26 +0100, Ross Paterson wrote:

> On Tue, Sep 09, 2008 at 10:59:17PM +0000, Duncan Coutts wrote:
> > 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. So not only could the
> > maintainer fix urls or whatever but also adjust dependencies in the
> > light of test results. Consider the analogy to pristine tarballs and
> > debian or gentoo meta-data files. The former never changes for a
> > particular version, but the meta-data can be adjusted as the
> > distributors see fit.
>
> So if Debian or Gentoo etc repackage one of these packages in their
> distributions, what is the pristine tarball that they use?

They use the one and only pristine tarball. As for what meta-data they
choose, that's up to them, they have the choice of using the
original .cabal file in the .tar.gz or taking advantage of the updated
version.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Ketil Malde-5
In reply to this post by Duncan Coutts
Duncan Coutts <[hidden email]> writes:

> So we should think about how to make it less confusing. Perhaps like
> distributors use an extra revision number we should do the same. I had
> hoped that would not be necessary but that's probably not realistic.

If we go this route, it'd be nice to have a distinguishable syntax,
like Gentoo's .rN, so that we don't have to remember whether it's
digit four or five that signifies "administrative" changes.

-k
--
If I haven't seen further, it is by standing in the footprints of giants
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Duncan Coutts
On Wed, 2008-09-10 at 12:09 +0200, Ketil Malde wrote:
> Duncan Coutts <[hidden email]> writes:
>
> > So we should think about how to make it less confusing. Perhaps like
> > distributors use an extra revision number we should do the same. I had
> > hoped that would not be necessary but that's probably not realistic.
>
> If we go this route, it'd be nice to have a distinguishable syntax,
> like Gentoo's .rN, so that we don't have to remember whether it's
> digit four or five that signifies "administrative" changes.

Yes, it must be distinguished because we cannot constrain the upstream
maintainers version policy. We do not know and should not care how many
version places they use.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Wolfgang Jeltsch-2
In reply to this post by Duncan Coutts
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Brandon S Allbery KF8NH
On 2008 Sep 10, at 6:48, Wolfgang Jeltsch wrote:
> Am Mittwoch, 10. September 2008 11:47 schrieben Sie:
>> 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.


Everyone who manages packages runs into this, and all of them use  
revision numbers like this.  (.rN for gentoo was already mentioned;  
BSD ports and MacPorts use _, RPM uses -.  Depot collections at CMU  
also use -.)

And while we're on that topic, most of them also have an "epoch" which  
overrides the version number.  If for some reason an updated package  
*doesn't* change the version, or goes backwards (because of a major  
bug leading to backing off the new release), you increase the epoch so  
dependent packages don't get confused when it's re-released.  If we're  
considering modifying hackage's versioning, we should probably decide  
if we want/need this now instead of having to add it in later when  
something major goes *boom*.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Duncan Coutts
On Wed, 2008-09-10 at 11:49 -0400, Brandon S. Allbery KF8NH wrote:

> On 2008 Sep 10, at 6:48, Wolfgang Jeltsch wrote:
> > Am Mittwoch, 10. September 2008 11:47 schrieben Sie:
> >> 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.
>
>
> Everyone who manages packages runs into this, and all of them use  
> revision numbers like this.  (.rN for gentoo was already mentioned;  
> BSD ports and MacPorts use _, RPM uses -.  Depot collections at CMU  
> also use -.)
>
> And while we're on that topic, most of them also have an "epoch" which  
> overrides the version number.  If for some reason an updated package  
> *doesn't* change the version, or goes backwards (because of a major  
> bug leading to backing off the new release), you increase the epoch so  
> dependent packages don't get confused when it's re-released.  If we're  
> considering modifying hackage's versioning, we should probably decide  
> if we want/need this now instead of having to add it in later when  
> something major goes *boom*.

We've thought about this and we think we do not need epoch numbers since
we're in the lucky position of doing the upstream versioning.

http://hackage.haskell.org/trac/hackage/ticket/135

Hmm, I think the discussion on that ticket must have been in an email
thread in cabal-devel.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Brandon S Allbery KF8NH
On 2008 Sep 10, at 17:51, Duncan Coutts wrote:
>> dependent packages don't get confused when it's re-released.  If  
>> we're
>> considering modifying hackage's versioning, we should probably decide
>> if we want/need this now instead of having to add it in later when
>> something major goes *boom*.
>
> We've thought about this and we think we do not need epoch numbers  
> since
> we're in the lucky position of doing the upstream versioning.

Are we?  I think the package author has final say if a package needs  
to be backed off, and any packages released between the rollback and  
the next release with dependencies on the backed-off package will be  
problematic, no matter how draconian hackage's version checking is.  
(This is a different situation from datecode versions as in the trac  
ticket.)

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Duncan Coutts
On Wed, 2008-09-10 at 18:35 -0400, Brandon S. Allbery KF8NH wrote:

> On 2008 Sep 10, at 17:51, Duncan Coutts wrote:
> >> dependent packages don't get confused when it's re-released.  If  
> >> we're
> >> considering modifying hackage's versioning, we should probably decide
> >> if we want/need this now instead of having to add it in later when
> >> something major goes *boom*.
> >
> > We've thought about this and we think we do not need epoch numbers  
> > since
> > we're in the lucky position of doing the upstream versioning.
>
> Are we?  I think the package author has final say if a package needs  
> to be backed off, and any packages released between the rollback and  
> the next release with dependencies on the backed-off package will be  
> problematic, no matter how draconian hackage's version checking is.  
> (This is a different situation from datecode versions as in the trac  
> ticket.)

I'm not quite sure I follow. Certainly it's the author/maintainer who
decides the version number. It's up to them to pick it, but they know
the ordering of version numbers.

As I understand it, epochs were mainly introduced to cope with
un-cooperative upstream maintainers whereas here maintainers already
have to specify a version number in the Cabal/Hackage scheme and there's
no way for them to pretend or unilaterally declare that 3 < 2 or any
other such silliness.

To account for having experimental versions available at the same time
as stable versions we're planning to let maintainers add a
suggested/soft version constraint. Is that related to what you mean by
"backing off" and "rollback"?

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Brandon S Allbery KF8NH
On 2008 Sep 10, at 18:43, Duncan Coutts wrote:

> On Wed, 2008-09-10 at 18:35 -0400, Brandon S. Allbery KF8NH wrote:
>> On 2008 Sep 10, at 17:51, Duncan Coutts wrote:
>>>> dependent packages don't get confused when it's re-released.  If
>>>> we're
>>>> considering modifying hackage's versioning, we should probably  
>>>> decide
>>>> if we want/need this now instead of having to add it in later when
>>>> something major goes *boom*.
>>>
>>> We've thought about this and we think we do not need epoch numbers
>>> since
>>> we're in the lucky position of doing the upstream versioning.
>>
>> Are we?  I think the package author has final say if a package needs
>> to be backed off, and any packages released between the rollback and
>> the next release with dependencies on the backed-off package will be
>> problematic, no matter how draconian hackage's version checking is.
>> (This is a different situation from datecode versions as in the trac
>> ticket.)
>
> I'm not quite sure I follow. Certainly it's the author/maintainer who
> decides the version number. It's up to them to pick it, but they know
> the ordering of version numbers.
>
> As I understand it, epochs were mainly introduced to cope with
> un-cooperative upstream maintainers whereas here maintainers already
> have to specify a version number in the Cabal/Hackage scheme and  
> there's

That is one use.  The far more common use, at least in FreeBSD ports,  
is when a version of a port has to be backed off; if any subsequently  
released packages depend on the backed-off version, things get nasty  
when the port is re-updated later.  This may not involve the port  
author; it could be an unexpected interaction with an updated  
dependency under certain circumstances.

"Backed off", in the FreebSD context, means an older version of the  
port is restored from CVS; in the context of Hackage it means removing  
the broken version and making the previous version the current version.

Basically, you *do* have control over this... but it's possible for  
the effects to propagate rather widely before such an interaction is  
discovered, resulting in needing to revise either many packages to  
reflect the corrected dependency... or updating one epoch.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Duncan Coutts
On Wed, 2008-09-10 at 18:53 -0400, Brandon S. Allbery KF8NH wrote:

> > As I understand it, epochs were mainly introduced to cope with
> > un-cooperative upstream maintainers whereas here maintainers already
> > have to specify a version number in the Cabal/Hackage scheme and  
> > there's
>
> That is one use.  The far more common use, at least in FreeBSD ports,  
> is when a version of a port has to be backed off; if any subsequently  
> released packages depend on the backed-off version, things get nasty  
> when the port is re-updated later.  This may not involve the port  
> author; it could be an unexpected interaction with an updated  
> dependency under certain circumstances.
>
> "Backed off", in the FreebSD context, means an older version of the  
> port is restored from CVS; in the context of Hackage it means removing  
> the broken version and making the previous version the current version.

Ok, so we never remove packages. So that's ok. You could fix the above
problem in two ways, adjust the suggested version constraint (which is
of course still vapourware) or upload a new version.

(Well, we sometimes remove packages that were uploaded without the
consent of the author. But that does not apply here.)

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Ross Paterson
In reply to this post by Duncan Coutts
On Wed, Sep 10, 2008 at 10:07:54AM +0000, Duncan Coutts wrote:
> On Wed, 2008-09-10 at 10:26 +0100, Ross Paterson wrote:
> > So if Debian or Gentoo etc repackage one of these packages in their
> > distributions, what is the pristine tarball that they use?
>
> They use the one and only pristine tarball. As for what meta-data they
> choose, that's up to them, they have the choice of using the
> original .cabal file in the .tar.gz or taking advantage of the updated
> version.

Since the modified version may contain essential fixes, they'll almost
certainly want that.  And they'll want to keep their mods separate, so
the updated .cabal file becomes another part of the upstream source, with
secondary versioning.  To which they add a third level of versioning for
their distro packaging.  And all this versioning is real; it's keeping
track of significant changes at each stage.

And then there's the psychological effect.  Make it easier to clean up
broken releases afterwards, and you'll have more of them.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

John Meacham
In reply to this post by Iavor Diatchki
The usual solution to this is the 'release version', which is used in
most (all?) other packaging systems. namely, you have foo-1.2-4, where 4 is the
release version which documents what version the meta-info is. For
instance, when bugs are fixed in the rpm spec file or deb package that
number is bumped and it is independent of the underlying packaged
softwares release. It would be very useful if hackage could support
something like this.

        John
 
--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Austin Seipp
> The usual solution to this is the 'release version', which is used in
> most (all?) other packaging systems. namely, you have foo-1.2-4, where 4 is the
> release version which documents what version the meta-info is. For
> instance, when bugs are fixed in the rpm spec file or deb package that
> number is bumped and it is independent of the underlying packaged
> softwares release. It would be very useful if hackage could support
> something like this.
>
>         John
>  

Hi John,

Hackage currently does not support this policy because of
e.g. dependency tracking - previously hackage *was* allowed to upload
packages of the form 'foo-1.2.3-unstable' but the problem was that it
includes the -unstable as part of the version number. In the general
case - arbitrary identifier suffixes as part of the version - when
someone just specifies a dependency on 'foo', does foo-1.0-bar >
foo-1.0-baz or not?

Duncan 'fixed' hackage and put the restriction on the upload form - at
the time I discussed this with him due to a problem with hsgnutls
because it had the -barracuda suffix on the package version.

In the case of meta-info specifying doc versions, I think we could
allow package names of the form 'x.y.z_n' where x y z and n can only
be integers. Then statements of the form e.g. 'foo-2.0_4 > foo-2.0_3'
make sense and cabal and cabal install can understand this - of
course, ghc-pkg won't accept such a version identifier, so it will
only have meaning to cabal but in the case of documentation fixes and
the like that's not much of a big deal really.

Austin
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

Duncan Coutts
In reply to this post by John Meacham
On Wed, 2008-11-19 at 20:25 -0800, John Meacham wrote:
> The usual solution to this is the 'release version', which is used in
> most (all?) other packaging systems. namely, you have foo-1.2-4, where 4 is the
> release version which documents what version the meta-info is. For
> instance, when bugs are fixed in the rpm spec file or deb package that
> number is bumped and it is independent of the underlying packaged
> softwares release. It would be very useful if hackage could support
> something like this.


There are two solutions to this, one is to say it's just a convention,
eg using 1.2.4 when you give it your meaning of 1.2_4. The reason deb,
rpm etc need to distinguish the extra version is precisely because they
do not control the upstream version number. Of course in the case of
package authors uploading packages to hackage that is not the case. It's
an upstream packaging format, not a downstream one.

However when we want to manage a collection of packages on hackage then
it is a bit more like a downstream distro and in that case there is a
stronger argument for making tweaks to meta-data (without uploading new
tarballs) and recording those revision numbers. Eg relaxing or
tightening versions of constraints as new information becomes available.

One possibility there is to keep a version of the .cabal file outside of
the tarball in the hackage index and record a x-hackage-revision: 3
field in that. It'd be incremented each time someone (author/maintainer
or packager collection herder) makes a tweak.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hackage policy question

John Meacham
Well, my main concern is that I have projects that have several
distribution formats, tarball, rpm, deb, and hopefully hackage
(alongside the others as equals). I don't want the version numbers to
get out of sync though, just because I have to reroll the hackage, or
rpm, or whatever release, I don't want to have to artificially increase
its version number such that it gets out of sync with the actual version
number of the package. For instance, I have a yum repository that
contains my various projects (DrIFT, jhc, etc..) and bumping the release
version is what I need to do to get 'yum update' to grab new versions,
but I don't want to have to rerelease hackage, tarball, or deb versions
to keep my version numbers in sync just for fixing an rpm or
distribution compatability issue. With rpm I don't have to do this since
it has a release version, so I am looking for something similar on the
hackage side of things.

        John

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12