[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R



On 2013-04-03 20:17:47 +0200, Philipp Kern wrote:
> On Wed, Apr 03, 2013 at 01:28:58PM +0200, Vincent Lefevre wrote:
> > > I pretty much agree. But what's the problem here? That xulrunner and
> > > iceweasel have rdeps in the archive that aren't necessarily
> > > compatible with a new version of iceweasel and hence introducing yet
> > > another transition whenever the targeted release changes.
> > I suppose that iceweasel could be built against the libraries from
> > testing. Then AFAIK, there remains a few rdeps problems, concerning
> > libmozjs and xulrunner (which must match the iceweasel version),
> > but this can be resolved by having both versions installed (this
> > is possible).
> 
> I said rdeps.

I know.

> Packages that depend on iceweasel and xulrunner. While the latter is
> coinstallable, the former is not.

It seems that most reverse dependencies for iceweasel are l10n
packages and extensions, so that one can consider them as part
of the upgrade. The remaining dependencies seem to have a form
like iceweasel | www-browser. So, what would be wrong?

Not also that in practice, many (most?) users will use a backport.
So, if some real reverse dependency would be affected by a change
in the iceweasel version, it rather needs to be fixed now.

> > > > And concerning transitions, you don't need a freeze to block them.
> > > As if it would be that easy. c.f. R, which this thread is about and which
> > > didn't change any package name.
> > You can see that concerning R, the freeze was pretty useless to avoid
> > some problems. Now, the freeze only concerns testing. And it is easy
> > to prevent packages from migrating to testing. A spurious RC bug is a
> > solution.
> 
> I interpreted your argument as being different:
> 
> >>> They should normally be detected when the package is uploaded in
> >>> unstable.
> >>> And concerning transitions, you don't need a freeze to block them.
> 
> Hence yes, we could block packages in unstable from being updated.
> Transitions also happen for unstable which cause temporary
> uninstallability, so I'm not sure what block you're talking about then.

I mean the update of the package in testing. A RC bug is a way to
block transitions from happening there; a freeze is not needed.

Concerning unstable, freeze or not, you can't really block updates
there (as this can be seen with R).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Reply to: