Re: Hackage revisions and the current breakage of https://jenkins.debian.net/view/haskell/job/haskell-package-plan/
Hi Joachim
> 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.
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,
* or incorporate revisions into our Debian naming scheme
and then apply the revision changes by the normal
upstream package upgrade process.
> 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.
Yes, indeed. So then one either makes an explicit patch from the r1 revision
and adds it to Debian metadata or, if we follow revisions as version
numbers, one upgrades to foo-1.0r1 upstream and it's done.
> But the script could be smarter about applying the patches to the
> pristine versions rather than to revisions.
That's for sure.
Reply to: