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 <[email protected]> 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 >
