Re: Hackage revisions and the current breakage of https://jenkins.debian.net/view/haskell/job/haskell-package-plan/
I guess that's the point that merits asking Herbert
to sacrifice a bit of his time and have a look at our questions.
On Sun, Jun 24, 2018 at 11:06 AM, Ilias Tsitsimpis <iliastsi@debian.org> wrote:
> 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: