Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Fri, Apr 19, 2013 at 12:16:11PM +0300, Niko Tyni wrote:
> On Thu, Apr 18, 2013 at 10:56:34AM +0200, Goswin von Brederlow wrote:
> > On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote:
> > > Niko Tyni <ntyni@debian.org> writes:
> > >
> > > > FWIW, I've done ABI-incompatible uploads of perl to experimental in the
> > > > past without changing the perlapi-* virtual package name or the libperl
> > > > SONAME. The aim was to experiment with different configuration options,
> > > > particularly 64-bit integers and 128-bit long doubles.
> > >
> > > > I certainly didn't support upgrades from those versions to the same
> > > > extent as I'd have done for unstable. OTOH, the packages were pretty
> > > > close to uninstallable on any non-minimal systems anyway, as we didn't
> > > > offer corresponding rebuilt XS modules in experimental.
> > >
> > > Oh, that's a good point. Yes, I hadn't thought about that specific case
> > > for testing ABI breakage in experimental.
> >
> > But then that simply is a broken upload. It will break horribly if you
> > install the experimental perl but keep other perl packages from sid.
>
> Well, it wasn't installable with perl packages in sid at the time due to a
> major version upgrade, which is why I was experimenting with incompatible
> ABI changes in the first place. (This was around perl/5.12.0-1 or so.)
That was OK then. Just in general one should think about such things.
Note: This isn't an attack of you or that upload. You/perl just have
the horrible luck of being used as an example.
> > You should have set the perlapi-* to include -experimental or
> > something to make it differ from sid. Having the perlapi-* provides
> > and depends makes this simple.
>
> First, this was against the policy at the time (since fixed with
> #579457.) Second, the ABI changes would also have required an extra
> libperl SONAME change with the implied NEW processing. That's
> too much overhead IMO.
Yeah, NEW queue processing can be bad. But if it realy is just
experimenting and the dependencies prevent mixed setups then I
wouldn't take the SONAME so serious. The SONAME change is there so old
and new stuff can coexist and migrate over time. That isn't applicable
to such an experimental situation.
> > Imho experimental packages should be made with the hope that they
> > could enter sid in the future. Sure they are for experimenting. But
> > say the experiment is successfull shouldn't the package go to sid? If
> > you have to redesign them at that point you will just introduce new
> > bugs at that point and restart the testing process again.
>
> The experiment in this case was seeing if the test suite passes on
> all architectures or not. It did not because long doubles are weird on
> powerpc, so I reverted the change. I then uploaded the next try (again,
> to experimental of course) without changing the perlapi-* or the SONAME.
>
> I still think that expecting full-blown ABI change handling for iterations
> like this in experimental is too much.
Totaly. Not for every iteration anyway. As long as mixing/breaking sid
is prevented with an SONAME change or dependencies that is fine. I
think ftp-master would kill you if every experimental upload had to go
through NEW.
As a side note: What you did probably shouldn't have been using
experimental at all. This should have gone to the long proposed "build
me this package" buildd extension. All you wanted (it sounds like) was
to compile the package and see the results of the built time test
suite. It would be nice if someone would work on implementing this
idea. That way maintainers could upload sources for test builds on
selective archs.
MfG
Goswin
Reply to: