[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 Mon, 1 Apr 2013 15:46:44 +0200
Rene Engelhard <rene@debian.org> wrote:

> On Mon, Apr 01, 2013 at 02:23:36PM +0100, Neil Williams wrote:
> > Having packages in experimental does not block the ability to test or
> > upload other packages which depend on functionality in those new
> > versions - you just need an appropriate setup, maybe a chroot.
> Wrong. When I upload something which depends on a package which
> isn't available this is uninstallable -> useless.

It is installable from experimental if the local setup is correct. It's
only a change to apt sources and preferences, in a chroot if necessary.
How trivial do you want it?

All uploads not destined for wheezy go into experimental, all packages
in unstable and experimental are available for builds within
experimental. New stuff which would break things in unstable goes into
experimental. What's so hard about that?

It's not as if you're trying to mix Debian and Ubuntu using MultiArch
across three architectures to try and debug assembly code for a new
architecture for which there is currently no hardware... just for

> > Even if you think there are a few days between the time taken to process
> > NEW for experimental vs NEW for unstable, I've seen no evidence of that
> > and it's not as if a few days are really going to matter. (If it's that
> > critical, find a webhost running Debian and install reprepro.)
> A few days? There's stuff there *for months*?

That's not my experience and hasn't been for a few years now. There
again, the FTP team are busy with the release too. Live with it or
find some way to help that team. Why should that excuse interrupting
the release team and making things *worse*?

> > What's so hard about that with the R packages?
> Read and think again, please.

So there's nothing different in how R packages need to do this, so
there's no problem.
> I am not caring about R and I am not defeinibg Direk. In contrast,
> he should have known that he shouldn't upload.
> I am telling about the general case.
> That your simple toy packages are not affected by this because they don't
> have as much r-deps as e.g. libreoffice. fine. But that doesn't make
> the problem go non-existant.

I've worked on quite a few packages with this method over the years,
some core stuff like curl, cairo, ldap, cups, etc. and then there's all
the cross-build, multiarch stuff which is often dealing with toolchains
and low level libraries. Don't lecture me about rdeps and dismiss the
advice of your peers as the ramblings of fly-by-night maintainers of
"toy" packages. Everything related to R is a toy project to me, why
should your toy project interfere with my development time?

We're in the late stages of a release, that *requires* changes in how
your R packages are handled.

It requires some effort: yes
It requires a little thought: yes
It requires that you think about teams other than your own: YES!
It works: yes
It disturbs your workflow: yes - don't expect apologies for that.

Deal with it and don't expect everyone else to pick up the mess when
you can't be bothered to think of those working on the release or in
other teams who are also desperately trying to hold things together in
the hope that the release will happen *real soon* now and make our
lives easier too.

There are more people involved in this than your pet R project and
more than just the release team and the FTP team. Most of us are
quietly doing the right thing and using experimental or external
repositories but we're still getting the work done. Please, stop
getting in the way! It really isn't hard.

Just upload the epoch version to unstable to match testing, 1:3.0.0 to
experimental and move on. We've all wasted enough time on this already.


Neil Williams

Attachment: pgpd_epgJLenq.pgp
Description: PGP signature

Reply to: