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 example. > > 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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpB083QuwQpu.pgp
Description: PGP signature