> 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 [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
