Re: guava-libraries 18?
On Tue, Oct 28, 2014 at 03:29:33PM +0000, Stephen Nelson wrote:
> On Tue, Oct 28, 2014 at 2:38 PM, Emmanuel Bourg <ebourg@apache.org> 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
Reply to: