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
