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.
