On Tue, Oct 28, 2014 at 03:29:33PM +0000, Stephen Nelson wrote: > On Tue, Oct 28, 2014 at 2:38 PM, Emmanuel Bourg <[email protected]> wrote: > > > There is another point worth discussing I think. When we want to fork a > > package foo 1.0 because the version 2.0 is incompatible, do we: > > > > 1. duplicate the package foo as foo-1 and upgrade foo to the version 2. > > Every reverse dependency that doesn't work with the version has to be > > updated to use the new package foo-1. > > > > 2. fork and upgrade the package foo as foo-2. The package that need the > > new version depend on foo-2 and the other remain unchanged. > > > > > I agree that solution 1 is better. It's counter intuitive that > guava-libraries-18 > could actually have version 19 of the library. Also a package name without > a version number within it e.g. guava-libraries, in general should track > the latest version that has been packaged and incorporated within Debian.
+1 (with a caveat) Keep in mind when forking the package that solution 1 requires the "old" foo-1 package to go through the NEW queue, which could take some time. You could find yourself waiting to fix rdeps of foo-1; meanwhile, the new foo is causing FTBFS bugs on those rdeps. It would be nice if we could have some determinism in the transaction. tony -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
