Re: Hackage revisions and the current breakage of https://jenkins.debian.net/view/haskell/job/haskell-package-plan/
On Sat, Jun 23, 2018 at 08:31AM, Mikolaj Konarski wrote:
> On Fri, Jun 22, 2018 at 08:12PM, Joachim Breitner wrote:
> > Note that I intentionally did not make it completely ignore revisions.
> > Consider this situation:
> >
> > * Debian has text-1.0 and foo-1.0
> > * foo-1.0r0 depends on text < 1.1
> > * Later someone added a revision to foo, and
> > foo-1.0r1 depends on text < 1.2
> > * I plan to upgrade text to 1.1, so I bump it in the package plan. I
> > do this to find out what packages this will break.
> >
> > Under the current scheme, test-packages will not complain, because foo
> > is compatible with 1.1. I go ahead and upgrade text.
The above will break as soon as you upload text-1.1 on Debian, since the
uploaded foo-1.0 depends on 'text < 1.1', right?
> > If we change that, it would say that I cannot upgrade text yet because
> > it believes some reverse dependencies are not compatible with the new
> > version yet.
So my question is, do you think it will be useful to encounter that
breakage early on (while updating package-plan), or do you feel it will
introduce unnecessary complexity?
> Oh, that's shrewd, but my gut-feeling would be to simplify it
> and make it less fragile by deciding to
> * either completely ignore revisions and apply them
> as explicit patches, if needed,
This is what we already do for the uploaded packages.
> * or incorporate revisions into our Debian naming scheme
> and then apply the revision changes by the normal
> upstream package upgrade process.
Since our packaging workflow is based on upstream tarballs, this will be
a little bit harder to be implemented, since there is no tarball for
version foo-1.0r1 which we can download from Hackage. We would have to
download foo-1.0r0 and metadata for foo-1.0r1 and repack. Not
impossible, but it might not worth the trouble.
--
Ilias
Reply to: