Re: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Sent from my MetroPCS 4G LTE Android device
Re: Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Fri, 2013-04-05 at 13:09:51 +0100, Ian Jackson wrote: Guillem Jover writes (Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)): Well, I strongly disagree that in general using epochs for packaging mistakes is a good practice (and I've thought so even before Ubuntu existed). The main purpose of epochs is to be able to handle mistakes or changes in the version numbering itself. Say upstream resets their versioning from v450 to 0.0.0, or from date based 20130404 to 0.0.0 (although the packager could have avoided that by prefixing with 0.), or if they used something like 1.210 and they meant 1.2.10 (svgalib), or a package takes over another's name (git). I agree entirely with what Guillem says. Also, introducing an epoch where there was none in an NMU should be frowned upon, unfortunately I've seen multiple instances of these in the recent past, something I'd be very upset if it happened to any of the packages I maintain. I wonder if this should be explicitly stated in the dev ref. Yeah, I guess, I'll try to come up with a patch in the next weeks (added to my TODO list). Thanks. Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130504143535.gb11...@gaara.hadrons.org
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 nt...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130423122218.GA26534@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote: On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote: 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. Welcome to experimental. Stuff might break, stuff might be deliberately broken, ... I might also not properly manage abi changes in libraries in experimental, especially when it is me packaging snapshots. /Sune I sure hope you mean breakages between different experimental versions. Not breakages compared to stable/testing/unstable versions. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130423122357.GB26534@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-23 14:23:57 +0200, Goswin von Brederlow wrote: On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote: On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote: 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. Welcome to experimental. Stuff might break, stuff might be deliberately broken, ... I might also not properly manage abi changes in libraries in experimental, especially when it is me packaging snapshots. /Sune I sure hope you mean breakages between different experimental versions. Not breakages compared to stable/testing/unstable versions. You should also consider breakage between an experimental version and a future unstable version. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130423125918.gb1...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
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 nt...@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.) 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. 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. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419091611.GA4918@madeleine.local.invalid
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote: 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. Welcome to experimental. Stuff might break, stuff might be deliberately broken, ... I might also not properly manage abi changes in libraries in experimental, especially when it is me packaging snapshots. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkn2505.fhs.nos...@sshway.ssh.pusling.com
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote: On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? Thomas Why wait? Well, ok, better not add changes to dpkg right now. :) Has anyone tried patching dpkg to keep the epoch in the deb filename? Anything break? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130418084850.GB24658@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote: Niko Tyni nt...@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. 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. 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. But that might just be me. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130418085634.GC24658@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-18 10:48 +0200, Goswin von Brederlow wrote: On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote: On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? Thomas Why wait? Well, ok, better not add changes to dpkg right now. :) Has anyone tried patching dpkg to keep the epoch in the deb filename? Yes, Guillem did so one year ago but reverted it. Anything break? Quite a few things, see the thread on http://lists.debian.org/debian-dpkg/2012/04/threads.html#00024. Cheers, Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738uoxlad@turtle.gmx.de
epoch in filenames for packages (was: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 04/18/2013 10:48, Goswin von Brederlow wrote: On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote: On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. It handles it by rejecting the later upload. The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? [...] Has anyone tried patching dpkg to keep the epoch in the deb filename? Anything break? [1] and [2] include at least dpkg-genchanges and dpkg-source breaking. [1] http://bugs.debian.org/551323 [2] http://bugs.debian.org/645895 Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/516fb70b.3010...@debian.org
Re: epoch in filenames for packages (was: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Thu, Apr 18, 2013 at 11:04:11AM +0200, Ansgar Burchardt wrote: On 04/18/2013 10:48, Goswin von Brederlow wrote: On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote: On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. It handles it by rejecting the later upload. I wonder what would happen if one uploaded a foo_1.2.3-1_amd64.deb with a new epoch but same hash. :) The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? [...] Has anyone tried patching dpkg to keep the epoch in the deb filename? Anything break? [1] and [2] include at least dpkg-genchanges and dpkg-source breaking. [1] http://bugs.debian.org/551323 [2] http://bugs.debian.org/645895 Ansgar Both of those are part of dpkg so they should have been patched too. I ment does anything outside of dpkg break. But that is probably covered in the thread mentioned in the last mail. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130418144535.GD21076@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sat, Apr 06, 2013 at 01:08:49PM +0900, Charles Plessy wrote: Le Sun, Mar 31, 2013 at 07:02:15PM -0400, Scott Kitterman a écrit : Depends: r-base-core (= 3.0.0~20130327) , r-base-core ( 4) or you could have an API virtual package: r-base-api-3.0 Hi Dirk and everybody, since we already have a substitution variable in most of the R packages (R:Depends), I think that we can use it to address the problem. First, let's define the problem: R broke backwards compatibility a couple of times since it has been packaged. Rebuilding packages is usually done swiftly, but there remains the problem of transitions to Testing and updates on the users computers. There is usually a gap of some years between breakages, so we do not want an over-engeneered solution. I like the idea of an api virtual package, as it requires little work from the parties involved and solves most of the problem. (The exception being that partial upgrades from Wheezy to Jessie will not be supported, but this is also the case in the current situation). In short: That is not an exception but THE intention. It's the whole point of having an api virtual package. In long: The R package breaks compatibility in such a way that a partial upgrade simply won't be functional. You either update them all or none. Till now installing any package compiles against a newer R API would pull in the newer r-base-core package to fullfill its version requirement but would not force old R packages already installed to also be updated. This leads to procken packages on partial update. Introducing the api virtual package will enforce that all R packages will be compiled against the same R API, against a compatible r-base-core. Installing one package compiled against the new R will force apt/aptitude to also update all the already installed R packages, which is what is required. - /usr/share/R/debian/r-cran.mk, which is used in most R packages and produces the R:Depends substitution variable, would make packages depend on the r-api virtual package instead of requiring a version equal or superior to the version of r-base-core used at build time. It might be enough to only depend on the api or you might need both, the api virtual package and a versioned depends for a minimum version. But that depends on the circumstances. Design it so that it is easy to have both and so that you don't miss updating the minimum version when required. - Next time R breaks backwards compatibility, Dirk would need to modify the Provides: line in debian/control and voilà, the new R core package can not be installed on a system without removing or upgrading the R library packages that were built with the old API. It might make sense to have a single file r-api-virtual-version (or so) in the source and generate the Provides: field and /usr/share/R/debian/r-cran.mk from that single source. Let's discuss the details on #704805 Have a nice week-end, MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130416131604.GC21076@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-04 21:08:45 +0200, Philipp Kern wrote: On Thu, Apr 04, 2013 at 05:14:54PM +0200, Vincent Lefevre wrote: I wonder whether there are packaged extensions […] So you didn't actually look. EOT from me, it's wasting my time. Sorry, I meant why instead of whether. As I've said in my message, packaged extensions are useless IMHO, because Firefox can handle upgrades gracefully. Multiple transitions then get entangled. I don't understand what you mean here. The freeze doesn't prevent that from happening in unstable. Our current freeze rules that apply to unstable prevent that in a social, not technical way. So, transitions could be avoided in a social way. No need for a freeze. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130415142214.ga18...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 15, 2013 at 04:22:14PM +0200, Vincent Lefevre wrote: So, transitions could be avoided in a social way. No need for a freeze. Let's see how well that works - look at the very first message in this thread. Neil -- signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-15 15:31:38 +0100, Neil McGovern wrote: On Mon, Apr 15, 2013 at 04:22:14PM +0200, Vincent Lefevre wrote: So, transitions could be avoided in a social way. No need for a freeze. Let's see how well that works - look at the very first message in this thread. My point is that: whether there is a freeze or not, it doesn't work well. On the other hand, one could argue that without the freeze system, it could have worked better: here the maintainer may have thought that because of the freeze, uploading the package wouldn't have hurt the next release. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130415143903.gb18...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/516174af.4060...@debian.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Holger Levsen wrote: On Montag, 1. April 2013, Steve M. Robbins wrote: Rather than accept the harm, surely the release team could simply roll back the upload in some manner? As I understand it, only by introducing an epoch in the package version. Or by using the 9.0.0+really0.99-1 version convention, which IMHO for is way better for cases of temporary backtracking like this. But in this particular case, leaving it alone in unstable would be better still. The release is not that far away, and it is not impossible to maintain packages in testing even when the package in sid has moved on. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130408053404.GA28322@elie.Belkin
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sat, Apr 06, 2013 at 01:08:49PM +0900, Charles Plessy wrote: I like the idea of an api virtual package, as it requires little work from the parties involved and solves most of the problem. I do not only like this but IMHO it is perfectly needed (as for any other language system we are packaging. - /usr/share/R/debian/r-cran.mk, which is used in most R packages and produces the R:Depends substitution variable, would make packages depend on the r-api virtual package instead of requiring a version equal or superior to the version of r-base-core used at build time. As I said previously in bug #659163 when R:Depends was introduced to regard some R api based on the expression R --version | head -n1 | perl -ne 'print / +([0-9]\.[0-9]+\.[0-9])/' which is independant from a certain package. I do regard the currently implemented solution as an unneeded restriction. Compared to the current implementation and the original suggestion in #659163 the r-api suggestion above is certainly the cleanest and best possible solution and I'm really in favour of this. - Next time R breaks backwards compatibility, Dirk would need to modify the Provides: line in debian/control and voilà, the new R core package can not be installed on a system without removing or upgrading the R library packages that were built with the old API. +1 (or even +2) Let's discuss the details on #704805 In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704805#10 Dirk Eddelbuettel wrote: I am not (yet?) sold: -- there is only one provider or r-api-* I can not parse whether this should be a question or a problem. -- we actually do have a greater than relation This is the current implementation and this is not really helpful. -- the version numbers already solve this No, they do not. An API level is something else than a version number. -- this was needed three times in ten years There is no point in properly solving a problem only because it does not happen very frequently. It can perfectly happen that it occures in a bad timing and a clean solution is always the goal we should approach inside Debian. I think we are overengineering this. I'm in great favour of the suggestion of Charles and IMHO it is far from overengineering - just following the usual standard procedure as it is implemented in all comparable situations in Debian. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130406152615.ga2...@an3as.eu
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, Mar 31, 2013 at 11:45:15AM -0500, Dirk Eddelbuettel wrote: A new major release R 3.0.0 will come out on Wednesday April 3rd, as usual according the the release plan and announcements [1]. It contains major internal changes [2] and requires rebuilds of all R packages. As I usually do, I started packaging pre-releases and rc candidates [3] based on March 24, 27 and 30 snapshots. Michael Rutter, who tirelessly backports (most of) my Debian R packages to Ubuntu, has also made builds of these R packages [4]. As for unstable, we have an issue as essentially all reverse-dependencies that are R packages will need to be rebuilt [5]. On testing, I get for 158 packages from `apt-cache rdepends r-base-core | grep -c r-cran-`. I am a little unclear what is required; is a binary rebuild sufficient, or is some change in the source code necessary? If the former, would it not be better just to ask the buildd administrators for a binary rebuild as opposed to having a new source version just for this? Julian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405075352.gc6...@d-and-j.net
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Le Fri, Apr 05, 2013 at 08:53:52AM +0100, Julian Gilbey a écrit : On Sun, Mar 31, 2013 at 11:45:15AM -0500, Dirk Eddelbuettel wrote: I am a little unclear what is required; is a binary rebuild sufficient, or is some change in the source code necessary? If the former, would it not be better just to ask the buildd administrators for a binary rebuild as opposed to having a new source version just for this? Hi Julian, for architecture-dependant packages, a binary rebuild is sufficient. For arch-independant packages, this facility is not available. In addition, with the Freeze, many of us had refrained from updating their packages, so this need for rebuilds is a good opportunity for update now that the relase is getting near. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405081019.ga32...@falafel.plessy.net
Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
Guillem Jover writes (Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)): Well, I strongly disagree that in general using epochs for packaging mistakes is a good practice (and I've thought so even before Ubuntu existed). The main purpose of epochs is to be able to handle mistakes or changes in the version numbering itself. Say upstream resets their versioning from v450 to 0.0.0, or from date based 20130404 to 0.0.0 (although the packager could have avoided that by prefixing with 0.), or if they used something like 1.210 and they meant 1.2.10 (svgalib), or a package takes over another's name (git). I agree entirely with what Guillem says. Also, introducing an epoch where there was none in an NMU should be frowned upon, unfortunately I've seen multiple instances of these in the recent past, something I'd be very upset if it happened to any of the packages I maintain. I wonder if this should be explicitly stated in the dev ref. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20830.48911.568030.146...@chiark.greenend.org.uk
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Le Sun, Mar 31, 2013 at 07:02:15PM -0400, Scott Kitterman a écrit : Depends: r-base-core (= 3.0.0~20130327) , r-base-core ( 4) or you could have an API virtual package: r-base-api-3.0 Hi Dirk and everybody, since we already have a substitution variable in most of the R packages (R:Depends), I think that we can use it to address the problem. First, let's define the problem: R broke backwards compatibility a couple of times since it has been packaged. Rebuilding packages is usually done swiftly, but there remains the problem of transitions to Testing and updates on the users computers. There is usually a gap of some years between breakages, so we do not want an over-engeneered solution. I like the idea of an api virtual package, as it requires little work from the parties involved and solves most of the problem. (The exception being that partial upgrades from Wheezy to Jessie will not be supported, but this is also the case in the current situation). - /usr/share/R/debian/r-cran.mk, which is used in most R packages and produces the R:Depends substitution variable, would make packages depend on the r-api virtual package instead of requiring a version equal or superior to the version of r-base-core used at build time. - Next time R breaks backwards compatibility, Dirk would need to modify the Provides: line in debian/control and voilà, the new R core package can not be installed on a system without removing or upgrading the R library packages that were built with the old API. Let's discuss the details on #704805 Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130406040849.gd22...@falafel.plessy.net
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
]] Vincent Lefevre On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote: Just to expand slightly on this, the problem you're both poking at is that during a freeze, our incentives are directed towards fixing RC bugs (because then we can release, which means we can then do what we prefer to, which (as you can see in the unconstrained periods), is to package new software, new upstream versions and so on). New code tends to be buggier than older, debugged code, so it's no surprise that we get more RC bugs in the non-freeze periods.. In general, bug-fix releases (which are also blocked by the freeze) don't introduce new bugs. Sometimes, they do, and except during this last stage of the freeze, it's not been particularly hard to get bug fixes into wheezy. As I have written elsewhere, I've had unblock requests go through less than five minutes after I filed the request. It's a little bit of extra book-keeping, sure, but it's not very onerous. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip42vlay@qurzaw.varnish-software.com
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Wed, Apr 03, 2013 at 10:29:26PM +0200, Vincent Lefevre wrote: 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? That the extensions also need to be updated, for the very least. 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. I presume most users of a backport don't use packaged extensions at all. 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. Multiple transitions then get entangled. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-04 16:23:33 +0200, Philipp Kern wrote: On Wed, Apr 03, 2013 at 10:29:26PM +0200, Vincent Lefevre wrote: 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? That the extensions also need to be updated, for the very least. If they are really maintained, they should probably have been updated already (that's one way to make sure that security fixes are applied). Otherwise it would be better to drop them. 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. I presume most users of a backport don't use packaged extensions at all. I wonder whether there are packaged extensions (and whether they could conflict with extensions installed by the user). Automatic handling by Firefox/Iceweasel works well. 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. Multiple transitions then get entangled. I don't understand what you mean here. The freeze doesn't prevent that from happening in unstable. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130404151454.gn31...@xvii.vinc17.org
Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Wed, 2013-04-03 at 20:18:44 +0200, Philipp Kern wrote: On Wed, Apr 03, 2013 at 03:33:30PM +0600, Andrey Rahmatullin wrote: On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote: And not, we do not have epochs to temporarily downgrade a package after a botched upload. c.f. imagemagick I'm pretty sure we do. It seems we usually upload a 2really1 package to fix that particular mistake without introducing an epoch. Which is a new custom that comes from Ubuntu who cannot reasonably use epochs. We can. Well, I strongly disagree that in general using epochs for packaging mistakes is a good practice (and I've thought so even before Ubuntu existed). The main purpose of epochs is to be able to handle mistakes or changes in the version numbering itself. Say upstream resets their versioning from v450 to 0.0.0, or from date based 20130404 to 0.0.0 (although the packager could have avoided that by prefixing with 0.), or if they used something like 1.210 and they meant 1.2.10 (svgalib), or a package takes over another's name (git). Epochs are a necessary evil, but they are distracting and clutter the version string, and if they can be avoided (by way of a 2really1 scheme) then IMO that should be prefered, beucase that's just temporary, usually until next Debian release. Also as it can be seen on the archive, once a version has been tainted (!?), uploaders tend to lower their resistance to increase the epoch even further. Also, introducing an epoch where there was none in an NMU should be frowned upon, unfortunately I've seen multiple instances of these in the recent past, something I'd be very upset if it happened to any of the packages I maintain. Something else I disagree is good practice is bumping an epoch to win the automatic upgradability against a downstream distribution version or 3rd-party package repository, because that makes us dependant on their practices. Some recentish examples of what _seems_ like gratuituous epoch introduction (there's probably many others): audit (NMU upload revert) clang (NMU upload revert, although with maintainer approval, because supposedly the package will get merged into llvm, but that only holds as long as the clang package disappears) file (NMU upload revert) fonts-ipafont-nonfree-jisx0208 (just for a tarball repack) ppl (no clear reason from the changelog?) usbutils (simply switching from 0.87 to 001 would have been fine) Not to mention things like fonts-sil-gentium with its date-base epoch. Something people seem to forget or be unware of, is that binary packages can contain a different version than the source they come from, so if you really need to bump the epoch for (say) a shared library package, you could do it just for that one, which would disappear when changing package name on the next SOVERSION bump. Or that when renaming the source and package names the epoch can be reset. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130404180927.ga31...@gaara.hadrons.org
Re: Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Thu, Apr 04, 2013 at 08:09:27PM +0200, Guillem Jover wrote: Also as it can be seen on the archive, once a version has been tainted (!?), uploaders tend to lower their resistance to increase the epoch even further. But once an epoch has been added, there is (arguably?) no problems with increasing it further. -- WBR, wRAR signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Thu, Apr 04, 2013 at 05:14:54PM +0200, Vincent Lefevre wrote: I wonder whether there are packaged extensions […] So you didn't actually look. EOT from me, it's wasting my time. Multiple transitions then get entangled. I don't understand what you mean here. The freeze doesn't prevent that from happening in unstable. Our current freeze rules that apply to unstable prevent that in a social, not technical way. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Fri, Apr 05, 2013 at 01:00:52AM +0600, Andrey Rahmatullin wrote: But once an epoch has been added, there is (arguably?) no problems with increasing it further. You're not really increasing ugliness in that case, but you are still screwing with any extant versioned relationships. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130404210243.ga2...@scru.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 13:37:59 -0500, Peter Samuelson wrote: [Vincent Lefevre] I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, there would be (almost) no delay. I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. Agreed: in July 2012, many - too many - RC bugs were already open. So when, in your estimation, would have been a better time to freeze? It depends on the rate these RC bugs are fixed. Only RC bugs affecting testing should be considered here. The question is then: were there many bugs affecting testing? If yes, why? Isn't the goal of unstable to detect RC bugs (in particular) before packages enter testing? If this fails too often, then something is wrong here. Moreover, perhaps there should be different steps in the freeze. Packages with a good history w.r.t. RC bugs (e.g. no RC bugs, or RC bugs quickly fixed) should not be concerned by an initial freeze. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403091430.gi31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote: And not, we do not have epochs to temporarily downgrade a package after a botched upload. c.f. imagemagick I'm pretty sure we do. It seems we usually upload a 2really1 package to fix that particular mistake without introducing an epoch. -- WBR, wRAR signature.asc Description: Digital signature
CUT and stable releases Was: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2013-04-02 at 17:24 +0100, Adam D. Barratt wrote: On 02.04.2013 16:35, Svante Signell wrote: The best solution would be having unstable _never_ frozen, at the cost of another repository during the freeze period. This was proposed some time ago, see http://lists.debian.org/debian-devel/2013/01/msg00273.html repeated here for convenience: That's a contentious definition of best. You also appear to have somewhat missed the point of my response to that original message, i.e. URL:http://lists.debian.org/debian-devel/2013/01/msg00274.html As I replied to you in http://lists.debian.org/debian-devel/2013/01/msg00275.html I did _not_ propose to remove testing! i) experimental being really for new stuff ii) unstable unfrozen always: - stable+1: if no freeze - testing after xx days as before - stable+1=unstable frozen at freeze time: if during freeze - testing - stable - stable+2: if in freeze - unstable And the frozen unstable/testing repository could cover a subset of the packages in unstable: The good ones. That would effectively reduce the freeze period. I'm still struggling to see how this is fundamentally different from the frozen suite which testing was introduced to replace, more than a dozen years ago. As per my earlier message referenced above, see URL:http://lists.debian.org/debian-devel/2000/08/msg00906.html for some detail of why frozen didn't work. It's not fundamentally different, but still different. And we can easily achieve CUT too, see below :) As proposed in the thread the idea should be written down at http://wiki.debian.org/ReleaseProposals Since this idea is new as far as I could see it's time do do that. FSVO new. I think it is new in the sense it adds a new dimension to the problem. I'm repeating the proposal again here, a little differently compared to before: t is current time. dt is the delay for packages to go from unstable to testing. T0 is the time for a freeze leading to next release. dT is the time from freeze to next stable release. T1 is the time the last stable release was made. RC0, RC1, ... are release candidates for next stable. - experimental: as before: experimental(t) - unstable: never frozen = unstable(t): Here we have the CUT :) And packahing of new upstream releases are not hindered by the freeze period. - testing: Case 1) No release: testing(t) = unstable(t-dt) Case 2) Release: testing(T0) = new archive called e.g. next_release_RC0, then RC1, ... until the last RC bug has been squeezed out leading to next stable. - stable: Case 1: No release: stable(t) = previous_release(T1) (of course with security updates, etc.) Case 2: Release: stable(t) = testing(T0+dT) (see above). Of course a lot of details have to be squeezed out but the above covers the main idea. What do you think? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1364984364.4439.24.ca...@amd64.my.own.domain
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 09:50:23 -0700, Russ Allbery wrote: Vincent Lefevre vinc...@vinc17.net writes: There are various problems with experimental, in particular dependencies are not necessarily listed, Huh? I have no clue what you could possibly be talking about, unless you're just saying that some packages in experimental are critically buggy. This was said in some Debian mailing-list. Not sure whether this is done on purpose or this was meant to be a bug. and upgrade from an experimental package is not supported (it generally works, but the maintainer doesn't have to take that into account). This is a bizarre statement to me. Why would you not take that into account as a maintainer? I always have for everything I've uploaded to experimental. IIRC, this was about a package that took care of an upgrade in its postinst script (something like that), but the maintainer didn't consider upgrade from experimental versions. There was also this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544480 which was closed immediately (and has never been fixed), just because some package from experimental was installed. The user is required to correct the installation manually. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403110705.gj31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 21:53:08 +0200, Philipp Kern wrote: Vincent, am Tue, Apr 02, 2013 at 05:07:27PM +0200 hast du folgendes geschrieben: I don't think that the status even of a big package like iceweasel is satisfactory. 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). Having different versions of some libs installed at the same time may not really be satisfactory, but a very old version of iceweasel is worse, IMHO. 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. There is no need to freeze *all* the packages. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403112858.gk31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 09:48:34 -0700, Russ Allbery wrote: Vincent Lefevre vinc...@vinc17.net writes: On 2013-04-02 14:29:46 +0100, Neil Williams wrote: That is not how it actually works out. Policy changes are made which require old packages to build with new flags, compilers and toolchain packages get upgraded and introduce new failure modes, QA tools improve and catch more corner cases. Those things no longer happen during a freeze, so the bug count has a chance to go down. Look at the graphs on bugs.debian.org - the RC count rises steadily outside of a freeze. The graph is meaningless. Many RC bugs can be due to transitions, which are specific (the freeze applies to *all* packagse). I don't see how that makes the graph meaningless. One of the points of a freeze is that we stop doing new transitions; in fact, that's one of the painful parts that everyone complaints about. How do you plan on keeping transitions from introducing new RC bugs without freezing? Transitions can occur in unstable. But their migration to testing would be blocked. This doesn't need a freeze. This is also due to the fact that more people are working on fixing RC bugs *now* instead of doing that before. Of course. And the only thing that we've ever managed to do to get that behavior change is to freeze. If you could get everyone to work on RC bugs outside of a freeze so that the RC bug count doesn't spike and then grow continuously every time we unfreeze, then indeed we would have a much nicer release process. Past experience tells us that's Hard; people work on RC bugs during the freeze and not to the same degree outside of the freeze. Perhaps some kind of freeze should occur earlier, i.e. when RC bugs start to become high, and unfreeze when the number of RC bugs is low enough. But I think one needs to differentiate: * RC bugs in testing and RC bugs in unstable only; * RC bugs from upstream (which shouldn't require much work from Debian if upstream is active) and Debian-specific RC bugs. Again, you're missing the whole inter-dependency issue. A new piece of software can introduce / reveal bugs in previously working software. Or a previously working piece of software can start to fail because hardware has moved on and is able to push more data through the software than previously envisaged leading to complex threading / timing issues. But my point is that this is true only for some particular packages Which collectively amount to probably 75% of the archive, since among other things that includes pretty much any package that uses a shared library. I don't understand what you mean here. If you mean that a shared library is breaking many packages, then such a bug should be fixed ASAP or the version should be reverted until the bug is fixed. The package wouldn't probably have the time to migrate to testing anyway. and this doesn't prevent developers from fixing RC bugs. Nothing prevents developers from fixing RC bugs at any time. They just don't in sufficient numbers to keep ahead of the incoming rate except during a freeze, both because the freeze drops the incoming rate (by, among other things, rejecting new transitions) New transitions should be rejected in some other way, not by freezing all the packages. and because more people actually work on RC bugs during a freeze. Then perhaps call it a RC big fix period, where people should work on RC bugs, but blocking new packages that fix bugs to experimental or unstable is not a solution in particular if the freeze lasts a long time. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403120812.gl31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote: Just to expand slightly on this, the problem you're both poking at is that during a freeze, our incentives are directed towards fixing RC bugs (because then we can release, which means we can then do what we prefer to, which (as you can see in the unconstrained periods), is to package new software, new upstream versions and so on). New code tends to be buggier than older, debugged code, so it's no surprise that we get more RC bugs in the non-freeze periods.. In general, bug-fix releases (which are also blocked by the freeze) don't introduce new bugs. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403121222.gm31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Wed, Apr 03, 2013 at 02:12:22PM +0200, Vincent Lefevre wrote: On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote: Just to expand slightly on this, the problem you're both poking at is that during a freeze, our incentives are directed towards fixing RC bugs (because then we can release, which means we can then do what we prefer to, which (as you can see in the unconstrained periods), is to package new software, new upstream versions and so on). New code tends to be buggier than older, debugged code, so it's no surprise that we get more RC bugs in the non-freeze periods.. In general, bug-fix releases (which are also blocked by the freeze) don't introduce new bugs. Case in point: http://www.h-online.com/open/news/item/Security-updates-break-ownCloud-installations-1834507.html We know from some projects that they have regression testing we deem sufficient to trust that assertion. But I'm not sure it's generally true. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
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. Packages that depend on iceweasel and xulrunner. While the latter is coinstallable, the former is not. 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. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Wed, Apr 03, 2013 at 03:33:30PM +0600, Andrey Rahmatullin wrote: On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote: And not, we do not have epochs to temporarily downgrade a package after a botched upload. c.f. imagemagick I'm pretty sure we do. It seems we usually upload a 2really1 package to fix that particular mistake without introducing an epoch. Which is a new custom that comes from Ubuntu who cannot reasonably use epochs. We can. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-03 20:14:32 +0200, Philipp Kern wrote: On Wed, Apr 03, 2013 at 02:12:22PM +0200, Vincent Lefevre wrote: In general, bug-fix releases (which are also blocked by the freeze) don't introduce new bugs. Case in point: http://www.h-online.com/open/news/item/Security-updates-break-ownCloud-installations-1834507.html Of course, there are exceptions. But you can see that the problem has been fixed very quickly (in less than 24 hours). If such a thing happens in Debian, the intermediate broken versions wouldn't even have the time to reach testing. One may also wonder whether the broken versions have sufficiently been tested. Perhaps not, to quickly fix a security problem. But even in this case, this may be the right thing to do. We know from some projects that they have regression testing we deem sufficient to trust that assertion. But I'm not sure it's generally true. Couldn't Debian packages have some field about the quality of regression testing? -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403200748.ga6...@xvii.vinc17.org
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 vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403202926.gb6...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote: When I said peripheral I meant in the sense that none of the Depends are used by anything else beyond R. I know it is not small -- there are now 4400 R packages on CRAN, and we have about 150 of those in Debian. I think it must be asked: what is the rationale of trying to re-package those for Debian? CRAN works. - Jukka. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402064022.GA26379@marx.bitnet
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Le 02/04/2013 08:40, Jukka Ruohonen a écrit : On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote: When I said peripheral I meant in the sense that none of the Depends are used by anything else beyond R. I know it is not small -- there are now 4400 R packages on CRAN, and we have about 150 of those in Debian. I think it must be asked: what is the rationale of trying to re-package those for Debian? CRAN works. As for perl, python, ruby, ... modules: only one software to install/upgrade/ fix security bug, ... : apt When R packages exist in Debian, I always install them from Debian. So that, I do not have to re-install them at each change of R version. I do not have to check if new upstream versions are available neither. apt does it for me. Now, as for perl (and probably other software with lots of modules), the creation of a R Debian package from a R CRAN package should be as automatic as possible (I did not check at all where we are on this point). Regards, Vincent - Jukka. -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515a85dc.2080...@free.fr
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 12:48:08AM +0300, Uoti Urpala wrote: IMO it's important to remember that it's fundamentally the release team that is at fault for problems here, not the R maintainer. Can you please remind me what you do for Debian? Aside from flame debian-devel. I've forgotten. Unstable has already been frozen for much longer than is in any way reasonable for either development of Debian, users of Debian unstable, or upstreams whose current software is either not being packaged at all or is only in experimental. I agree with this, but the release team are not the people who are on the critical path for getting us to release-ready, as per our current release process. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402081317.GA3371@debian
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 12:15:17AM +0200, Arno Töll wrote: So help speeding up the release process. The universal rebuttal to all complaints about the release process. Sadly it misses the point at the heart of most complaints: far too much work is needed to become release-ready, and there is not enough resource to do it. People who feel the release process is broken and care about Debian have a duty to discuss it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402081536.GB3371@debian
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 07:57:50AM +0300, Faidon Liambotis wrote: I don't think the time for this discussion is now, so I'll restrain myself from saying more. The release is near, and there's going to be plenty of time until the next freeze :) When the pain of the freeze will be a fast-fading memory, and we'll not bother trying to reform the release process until we're in the thick of it again, and if anyone dares suggest that the process is flawed at that point they'll be labelled a pariah and shunned from the village. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402082011.GC3371@debian
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote: You seem to believe that unstable is more important than stable releases. I do not. One of us is in the wrong project. If, you are suggesting here, that the release process in Debian is utterly set in stone and nobody may raise objections about it or try to work to address the problems that people have with it, then I guess *I'm* in the wrong project. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402082602.GD3371@debian
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Le mardi 02 avril 2013 à 09:15 +0100, Jonathan Dowland a écrit : The universal rebuttal to all complaints about the release process. Sadly it misses the point at the heart of most complaints: far too much work is needed to become release-ready, and there is not enough resource to do it. People who feel the release process is broken and care about Debian have a duty to discuss it. This is indeed Debian’s problem and needs discussion, but the roots lie in upstreams. It mostly comes down to the fact that upstreams of a growing number of projects are not able to synchronize their releases so that a single set of versions can all work together. Personally I think the best way to alleviate that problem would be to reduce the set of packages that are included in a stable release (and that also means in testing). But that is a high price to pay for the sole benefit of making releases easier. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1364893776.3634.849.camel@pi0307572
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-03-31 23:20:23 +0100, Neil Williams wrote: The length of the freeze is not the fault of the release team. The length of the freeze is down to all of the contributors to Debian not fixing enough RC bugs - I count myself in that, I've managed to get massively less done for this release than for previous ones. There are reasons, it doesn't change the reality that the freeze is still ongoing. I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, there would be (almost) no delay. I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402125235.gb31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 11:09:35 +0200, Josselin Mouette wrote: This is indeed Debian’s problem and needs discussion, but the roots lie in upstreams. It mostly comes down to the fact that upstreams of a growing number of projects are not able to synchronize their releases so that a single set of versions can all work together. Personally I think the best way to alleviate that problem would be to reduce the set of packages that are included in a stable release (and that also means in testing). But that is a high price to pay for the sole benefit of making releases easier. If neither upstream nor the Debian maintainer of some package is active and the package is rather buggy (e.g. with RC bugs not easy to fix), I don't think that the package should be in stable. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402130933.gc31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit : On 2013-03-31 23:20:23 +0100, Neil Williams wrote: The length of the freeze is not the fault of the release team. The length of the freeze is down to all of the contributors to Debian not fixing enough RC bugs - I count myself in that, I've managed to get massively less done for this release than for previous ones. There are reasons, it doesn't change the reality that the freeze is still ongoing. I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, Problem is: until you freeze, new RC bugs keep getting introduced. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402130943.gj6...@type.bordeaux.inria.fr
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 02.04.2013 13:52, Vincent Lefevre wrote: I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. If so, there was a good reason for that (i.e. pre-announced time-based freeze). As others have said (although ymmv) I don't think this is the appropriate time to get in to the pros / cons of that decision. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2b0f08e74fe8a44e3d83f679a0d93...@mail.adsl.funky-badger.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2 Apr 2013 14:52:35 +0200 Vincent Lefevre vinc...@vinc17.net wrote: On 2013-03-31 23:20:23 +0100, Neil Williams wrote: The length of the freeze is not the fault of the release team. The length of the freeze is down to all of the contributors to Debian not fixing enough RC bugs - I count myself in that, I've managed to get massively less done for this release than for previous ones. There are reasons, it doesn't change the reality that the freeze is still ongoing. I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, there would be (almost) no delay. I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. The release happens when (almost) all RC bugs are fixed, the freeze is to allow the existing bugs to be fixed whilst *protecting* the other packages from breakage caused by new software being uploaded. The RC bug count only ever comes down once a freeze is in place. New software causes new bugs, that's inescapable. To reduce the bug count, existing software must be fixed without allowing new software to continue breaking things and whilst making the absolute minimal changes to the software which is still working. *That* is the freeze. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpag6fmtZ2H6.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote: Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit : I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, Problem is: until you freeze, new RC bugs keep getting introduced. But I would say, not many. Or RC bugs also apply to old versions of the package. Moreover really new RC bugs are introduced on packages where upstream is active (since the version is new), so that they have a better chance to be fixed quickly. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402131538.gd31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 01:13:29PM +0100, Neil Williams wrote: On Mon, 1 Apr 2013 17:42:29 +0600 Andrey Rahmatullin w...@wrar.name wrote: On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote: Thanks for trading the R release cycle with Debian's and for delaying the release. The harm has already been done, so somebody should probably go and create a transition tracker for it? Rather than accept the harm, surely the release team could simply roll back the upload in some manner? Only by uploading older versions with bumped version numbers, and that still will cause testing and unstable to have different binaries. That is why we have epochs - an epoch is ignored for the purposes of the binary packages, see zlib1g and other packages using epochs. The existing tools have sane support for epochs, exactly to avoid these problems. http://packages.debian.org/sid/zlib1g 1:1.2.7.dfsg-13 http://ftp.uk.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.7.dfsg-13_amd64.deb dpkg -l | grep ':' The version currently in wheezy could be re-uploaded with a single change to the changelog to start using an epoch and using the version string currently in wheezy for the post-epoch string of the new version. If wheezy had foo 1.2.3-1 and unstable 2.0.0-1, the epoch version of 1.2.3 would be 1:1.2.3-1 which is newer than 2.0.0-1 but be compatible with 1.2.3-1 already in wheezy. Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. You would have to upload foo 1:1.2.3-2 to avoid the name clash. And not, we do not have epochs to temporarily downgrade a package after a botched upload. Esspecially when the package doesn't yet have a epoch. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402131824.GA10316@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2 Apr 2013 15:09:33 +0200 Vincent Lefevre vinc...@vinc17.net wrote: On 2013-04-02 11:09:35 +0200, Josselin Mouette wrote: This is indeed Debian’s problem and needs discussion, but the roots lie in upstreams. It mostly comes down to the fact that upstreams of a growing number of projects are not able to synchronize their releases so that a single set of versions can all work together. Personally I think the best way to alleviate that problem would be to reduce the set of packages that are included in a stable release (and that also means in testing). But that is a high price to pay for the sole benefit of making releases easier. If neither upstream nor the Debian maintainer of some package is active and the package is rather buggy (e.g. with RC bugs not easy to fix), I don't think that the package should be in stable. Whilst there are packages which are in that state and some of those can be removed, it isn't possible to remove such packages when there are multiple reverse dependencies. We cannot remove every package where both the maintainer and the upstream are inactive without also removing a lot of packages which have active teams. Equally, active teams don't have the bandwidth to take on the workload of all of their inactive dependencies. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpXV0CvcopJa.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre, le Tue 02 Apr 2013 15:15:38 +0200, a écrit : On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote: Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit : I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, Problem is: until you freeze, new RC bugs keep getting introduced. But I would say, not many. Yes, many. See some other reply: the RC bug count only really goes down during freezes. Moreover really new RC bugs are introduced on packages where upstream is active (since the version is new), so that they have a better chance to be fixed quickly. RC bugs are not only about upstream, it's also about packaging, transitions, etc. It can easily become an intractable mess if things keep getting changed. That's what the freeze it meant to avoid. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402132318.gl6...@type.bordeaux.inria.fr
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2 Apr 2013 15:15:38 +0200 Vincent Lefevre vinc...@vinc17.net wrote: On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote: Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit : I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, Problem is: until you freeze, new RC bugs keep getting introduced. But I would say, not many. Or RC bugs also apply to old versions of the package. That is not how it actually works out. Policy changes are made which require old packages to build with new flags, compilers and toolchain packages get upgraded and introduce new failure modes, QA tools improve and catch more corner cases. Those things no longer happen during a freeze, so the bug count has a chance to go down. Look at the graphs on bugs.debian.org - the RC count rises steadily outside of a freeze. Moreover really new RC bugs are introduced on packages where upstream is active (since the version is new), so that they have a better chance to be fixed quickly. Again, you're missing the whole inter-dependency issue. A new piece of software can introduce / reveal bugs in previously working software. Or a previously working piece of software can start to fail because hardware has moved on and is able to push more data through the software than previously envisaged leading to complex threading / timing issues. Even during a freeze, there are many many RC bugs opened for the first time and a lot of those are not in packages which have changed since the freeze began. No package is an island. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpJOMreCwOaH.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-01 02:34:41 +0200, Samuel Thibault wrote: Uoti Urpala, le Mon 01 Apr 2013 03:07:25 +0300, a écrit : Having latest upstream versions easily available to users is important for the development of many projects, That's what experimental is for. There are various problems with experimental, in particular dependencies are not necessarily listed, and upgrade from an experimental package is not supported (it generally works, but the maintainer doesn't have to take that into account). In short, experimental is not for the end user. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402142918.ge31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 14:17:17 +0100, Neil Williams wrote: The release happens when (almost) all RC bugs are fixed, the freeze is to allow the existing bugs to be fixed whilst *protecting* the other packages from breakage caused by new software being uploaded. You can still fix bugs while new software is uploaded, and more generally RC bugs should be fixed ASAP. The RC bug count only ever comes down once a freeze is in place. Developers should not wait for the freeze to fix RC bugs. New software causes new bugs, that's inescapable. But new software also causes existing bugs to be fixed. The number of bugs tend to decrease, in particular in bug-fix releases (note that such releases are also blocked by the freeze). To reduce the bug count, existing software must be fixed without allowing new software to continue breaking things and whilst making the absolute minimal changes to the software which is still working. *That* is the freeze. No, buggy new software that breaks things should not enter testing in the first place. That's what unstable/testing is for. New buggy packages should remain in unstable while new versions of good packages could still enter testing for the next release. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402145212.gf31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 15:23:18 +0200, Samuel Thibault wrote: Vincent Lefevre, le Tue 02 Apr 2013 15:15:38 +0200, a écrit : On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote: Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit : I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, Problem is: until you freeze, new RC bugs keep getting introduced. But I would say, not many. Yes, many. See some other reply: the RC bug count only really goes down during freezes. But many packages don't have new RC bugs. They are still blocked by the freeze. I don't think that the status even of a big package like iceweasel is satisfactory. Moreover really new RC bugs are introduced on packages where upstream is active (since the version is new), so that they have a better chance to be fixed quickly. RC bugs are not only about upstream, it's also about packaging, transitions, etc. It can easily become an intractable mess if things keep getting changed. That's what the freeze it meant to avoid. They should normally be detected when the package is uploaded in unstable. And concerning transitions, you don't need a freeze to block them. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402150727.gg31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 14:29:46 +0100, Neil Williams wrote: That is not how it actually works out. Policy changes are made which require old packages to build with new flags, compilers and toolchain packages get upgraded and introduce new failure modes, QA tools improve and catch more corner cases. Those things no longer happen during a freeze, so the bug count has a chance to go down. Look at the graphs on bugs.debian.org - the RC count rises steadily outside of a freeze. The graph is meaningless. Many RC bugs can be due to transitions, which are specific (the freeze applies to *all* packagse). This is also due to the fact that more people are working on fixing RC bugs *now* instead of doing that before. Again, you're missing the whole inter-dependency issue. A new piece of software can introduce / reveal bugs in previously working software. Or a previously working piece of software can start to fail because hardware has moved on and is able to push more data through the software than previously envisaged leading to complex threading / timing issues. But my point is that this is true only for some particular packages and this doesn't prevent developers from fixing RC bugs. -- Vincent Lefèvre vinc...@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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402152052.gh31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre, le Tue 02 Apr 2013 17:20:52 +0200, a écrit : This is also due to the fact that more people are working on fixing RC bugs *now* instead of doing that before. Which is one of the goals of freezing. I'm just tired of argumenting over something that was already discussed. Let's just work on the actual release at stake... Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402152433.gx6...@type.bordeaux.inria.fr
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2013-04-02 at 16:29 +0200, Vincent Lefevre wrote: On 2013-04-01 02:34:41 +0200, Samuel Thibault wrote: Uoti Urpala, le Mon 01 Apr 2013 03:07:25 +0300, a écrit : Having latest upstream versions easily available to users is important for the development of many projects, That's what experimental is for. There are various problems with experimental, in particular dependencies are not necessarily listed, and upgrade from an experimental package is not supported (it generally works, but the maintainer doesn't have to take that into account). In short, experimental is not for the end user. The best solution would be having unstable _never_ frozen, at the cost of another repository during the freeze period. This was proposed some time ago, see http://lists.debian.org/debian-devel/2013/01/msg00273.html repeated here for convenience: i) experimental being really for new stuff ii) unstable unfrozen always: - stable+1: if no freeze - testing after xx days as before - stable+1=unstable frozen at freeze time: if during freeze - testing - stable - stable+2: if in freeze - unstable And the frozen unstable/testing repository could cover a subset of the packages in unstable: The good ones. That would effectively reduce the freeze period. As proposed in the thread the idea should be written down at http://wiki.debian.org/ReleaseProposals Since this idea is new as far as I could see it's time do do that. The details can be discussed later on, when Wheezy is released. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1364916902.2302.136.ca...@s1499.it.kth.se
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 02.04.2013 16:35, Svante Signell wrote: The best solution would be having unstable _never_ frozen, at the cost of another repository during the freeze period. This was proposed some time ago, see http://lists.debian.org/debian-devel/2013/01/msg00273.html repeated here for convenience: That's a contentious definition of best. You also appear to have somewhat missed the point of my response to that original message, i.e. URL:http://lists.debian.org/debian-devel/2013/01/msg00274.html i) experimental being really for new stuff ii) unstable unfrozen always: - stable+1: if no freeze - testing after xx days as before - stable+1=unstable frozen at freeze time: if during freeze - testing - stable - stable+2: if in freeze - unstable And the frozen unstable/testing repository could cover a subset of the packages in unstable: The good ones. That would effectively reduce the freeze period. I'm still struggling to see how this is fundamentally different from the frozen suite which testing was introduced to replace, more than a dozen years ago. As per my earlier message referenced above, see URL:http://lists.debian.org/debian-devel/2000/08/msg00906.html for some detail of why frozen didn't work. As proposed in the thread the idea should be written down at http://wiki.debian.org/ReleaseProposals Since this idea is new as far as I could see it's time do do that. FSVO new. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/613c903831a5003cf7f8d2254668f...@mail.adsl.funky-badger.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 02 Apr 2013, Jukka Ruohonen wrote: On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote: When I said peripheral I meant in the sense that none of the Depends are used by anything else beyond R. I know it is not small -- there are now 4400 R packages on CRAN, and we have about 150 of those in Debian. I think it must be asked: what is the rationale of trying to re-package those for Debian? CRAN works. CRAN works, but it's not optimal. There's a reason why those packages are packaged, and why http://debian-r.debian.net exists. Don Armstrong -- Sometimes I wish I could take back all my mistakes but then I think what if my mother could take back hers? -- a softer world #498 http://www.asofterworld.com/index.php?id=498 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402164039.gk4...@rzlab.ucr.edu
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Jonathan Dowland j...@debian.org writes: On Mon, Apr 01, 2013 at 07:57:50AM +0300, Faidon Liambotis wrote: I don't think the time for this discussion is now, so I'll restrain myself from saying more. The release is near, and there's going to be plenty of time until the next freeze :) When the pain of the freeze will be a fast-fading memory, and we'll not bother trying to reform the release process until we're in the thick of it again, and if anyone dares suggest that the process is flawed at that point they'll be labelled a pariah and shunned from the village. I really don't think this is true. If someone tries to do that in a later discussion, I at least promise to point out that the freeze is long and uncomfortable and that, if we can come up with a better solution, we would definitely benefit. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878v50rikk@windlord.stanford.edu
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre vinc...@vinc17.net writes: On 2013-04-02 14:29:46 +0100, Neil Williams wrote: That is not how it actually works out. Policy changes are made which require old packages to build with new flags, compilers and toolchain packages get upgraded and introduce new failure modes, QA tools improve and catch more corner cases. Those things no longer happen during a freeze, so the bug count has a chance to go down. Look at the graphs on bugs.debian.org - the RC count rises steadily outside of a freeze. The graph is meaningless. Many RC bugs can be due to transitions, which are specific (the freeze applies to *all* packagse). I don't see how that makes the graph meaningless. One of the points of a freeze is that we stop doing new transitions; in fact, that's one of the painful parts that everyone complaints about. How do you plan on keeping transitions from introducing new RC bugs without freezing? This is also due to the fact that more people are working on fixing RC bugs *now* instead of doing that before. Of course. And the only thing that we've ever managed to do to get that behavior change is to freeze. If you could get everyone to work on RC bugs outside of a freeze so that the RC bug count doesn't spike and then grow continuously every time we unfreeze, then indeed we would have a much nicer release process. Past experience tells us that's Hard; people work on RC bugs during the freeze and not to the same degree outside of the freeze. Again, you're missing the whole inter-dependency issue. A new piece of software can introduce / reveal bugs in previously working software. Or a previously working piece of software can start to fail because hardware has moved on and is able to push more data through the software than previously envisaged leading to complex threading / timing issues. But my point is that this is true only for some particular packages Which collectively amount to probably 75% of the archive, since among other things that includes pretty much any package that uses a shared library. and this doesn't prevent developers from fixing RC bugs. Nothing prevents developers from fixing RC bugs at any time. They just don't in sufficient numbers to keep ahead of the incoming rate except during a freeze, both because the freeze drops the incoming rate (by, among other things, rejecting new transitions) and because more people actually work on RC bugs during a freeze. That's the fundamental constraint that any new release process needs to work with. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nfori8t@windlord.stanford.edu
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre vinc...@vinc17.net writes: There are various problems with experimental, in particular dependencies are not necessarily listed, Huh? I have no clue what you could possibly be talking about, unless you're just saying that some packages in experimental are critically buggy. and upgrade from an experimental package is not supported (it generally works, but the maintainer doesn't have to take that into account). This is a bizarre statement to me. Why would you not take that into account as a maintainer? I always have for everything I've uploaded to experimental. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjxgq3lc@windlord.stanford.edu
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
[Jonathan Dowland] On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote: You seem to believe that unstable is more important than stable releases. I do not. One of us is in the wrong project. If, you are suggesting here, that the release process in Debian is utterly set in stone and nobody may raise objections about it or try to work to address the problems that people have with it ECHAN? Did you quote the wrong text, or reply to the wrong message or even the wrong sender? Because your paraphrase seems to have nothing to do with the text you quoted. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402183124.gu4...@p12n.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
[Vincent Lefevre] I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, there would be (almost) no delay. I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. Agreed: in July 2012, many - too many - RC bugs were already open. So when, in your estimation, would have been a better time to freeze? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402183759.gv4...@p12n.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
]] Russ Allbery and this doesn't prevent developers from fixing RC bugs. Nothing prevents developers from fixing RC bugs at any time. They just don't in sufficient numbers to keep ahead of the incoming rate except during a freeze, both because the freeze drops the incoming rate (by, among other things, rejecting new transitions) and because more people actually work on RC bugs during a freeze. Just to expand slightly on this, the problem you're both poking at is that during a freeze, our incentives are directed towards fixing RC bugs (because then we can release, which means we can then do what we prefer to, which (as you can see in the unconstrained periods), is to package new software, new upstream versions and so on). New code tends to be buggier than older, debugged code, so it's no surprise that we get more RC bugs in the non-freeze periods.. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738v83g7d@xoog.err.no
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent, am Tue, Apr 02, 2013 at 05:07:27PM +0200 hast du folgendes geschrieben: I don't think that the status even of a big package like iceweasel is satisfactory. 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. 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. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Goswin, am Tue, Apr 02, 2013 at 03:18:24PM +0200 hast du folgendes geschrieben: And not, we do not have epochs to temporarily downgrade a package after a botched upload. c.f. imagemagick I'm pretty sure we do. SCNR Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, Apr 02, 2013 at 09:50:23AM -0700, Russ Allbery wrote: Vincent Lefevre vinc...@vinc17.net writes: and upgrade from an experimental package is not supported (it generally works, but the maintainer doesn't have to take that into account). This is a bizarre statement to me. Why would you not take that into account as a maintainer? I always have for everything I've uploaded to experimental. 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. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402200131.GA7442@madeleine.local.invalid
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Niko Tyni nt...@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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uasmxl4@windlord.stanford.edu
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 05:23:08AM +0600, Andrey Rahmatullin wrote: And even a month ago [1] there were no RC bugs that could be helped with by a random contributor, and that was the case for some time already. So I think it is unfair to say that random contributors are responsible for the freeze delay. [1]: http://lists.debian.org/20130301092949.gf7...@an3as.eu But the freeze was longer than two months and a few helping hands earlier could've speeded it up. ;-) Sure, at this point, we're almost there hence one gets the tricky problems. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Hi, On Montag, 1. April 2013, Steve M. Robbins wrote: Rather than accept the harm, surely the release team could simply roll back the upload in some manner? As I understand it, only by introducing an epoch in the package version. Which, understandably, is often frowned upon as an epoch never goes away and looks ugly. (For those caring about the look of version numbers.) Which is actually sane: you dont want versions to vanish, same versions pop up with different content, etc pp. So, also here: once you put something on the internet, it's out there and you cannot get it back. cheers, Holger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201304011038.55927.hol...@layer-acht.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, 31 Mar 2013 17:45:15 -0500 Dirk Eddelbuettel e...@debian.org wrote: On 1 April 2013 at 00:16, Josselin Mouette wrote: | I don’t understand how you can say it “worked before”. | Let’s say you backport a R package from wheezy to squeeze (something we | tried recently at work). The new R will install without a dependency | problem, and… all modules will stop working. | | Testing is fine, but within unstable the transition has to be done. | | Testing is not fine. The new R version could migrate to testing without Not if we blocked it. That's what I was trying to suggest. So you are relying on the release process to provide the block? Having the new version in unstable is much more likely to cause problems with backports as other packages will change to match the new API and then need those changes undone to be backportable. r-base_3.0.0~20130330 is one day old, there should be a new r-base_3.0.0-1 come April 3. ... or an epoch could be used to put unstable back to what is in testing and 3.0.0 could go into experimental, introducing the maximum version limitation and API versioning at the same time. | There are reasons why other interpreters have complex dependency | schemes: previously to avoid that. Not only your reverse dependencies | should only depend on the *sufficient* version of R (in this case, | certainly not the R version used to compile the package, which will lead | to transition blockades to testing), but they should stop installing | when the version of R becomes incompatible, and so far nothing | guarantees that. | | Perl has a perlapi-X.Y virtual package to avoid that. | Python generates python ( X.Y) dependencies to avoid that. | There are tons of similar schemes used across the Debian archive to | avoid such problems, from virtual packages, through autogenerated | dependencies, to package renames. | | It’s OK if you don’t know the best way to do that for your package. This We did not need for the previous 15 years that R has been part of Debian. How many R transitions have been done during a release freeze? How many at this perilously late stage of a release freeze? A lot of things can be done early in a release freeze and only cause a slight delay, if any. It is simply not possible to handle API changes in unstable at this stage of a release without *directly* delaying that release. The discussion of the rebuild request alone has required the attention of people from the FTP team, wanna-build team, release team and other DD's actively working on the release. Just because it hasn't caused a big discussion before doesn't mean that it wasn't a problem, just that it wasn't a big enough problem for lots of people to get involved. If the release team strongly insists that I ought to add this, I can. It has not been needed before. And Perl is an odd example as there are multiple APIs / versions used in parallel. We don't usually do that with R. Unstable now has a different API and version to testing, yes? Testing has a different API to stable (squeeze)? (I'm not sure) Wheezy will definitely have a different API to Jessie, so backporters will clearly need this kind of API version support. Looks like multiple APIs / versions are inevitable, block or no block. If multiple APIs / versions are never going to happen, then the API version support can be avoided. If there is any situation (i.e. as now) where multiple versions are desirable from your perspective (clearly not desirable from the release perspective, right now) then your own requirements mandate a change. Personally, I agree with Josselin - R looks like it needs precisely the same kind of API version limits as python or perl. Packages built for the old API must not allow installation of a version of the interpreter which breaks the API required by those packages until those packages have been rebuilt and have a dependency suitable for the new API. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgphRKULOC8qq.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit : Distributions that make latest software available are necessary for free software development. Again, that's one of the things experimental is for. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401094710.gx17...@type.youpi.perso.aquilenet.fr
Re: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote: Thanks for trading the R release cycle with Debian's and for delaying the release. The harm has already been done, so somebody should probably go and create a transition tracker for it? Rather than accept the harm, surely the release team could simply roll back the upload in some manner? Only by uploading older versions with bumped version numbers, and that still will cause testing and unstable to have different binaries. -- WBR, wRAR signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Samuel Thibault wrote: Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit : Distributions that make latest software available are necessary for free software development. Again, that's one of the things experimental is for. It is not. You can't reasonably install things from experimental rather than unstable by default, nor is there a flag for this really should be in unstable if not for badly managed release which would allow autoinstalling those packages. Consider the GDB example I mentioned earlier; GDB 4.5 should be installed by default for users of unstable, rather than expecting them to notice that their system has become too outdated, investigate it and find out which package to manually update. It is unreasonable to tell the users and upstreams that Debian is going to keep users on a known inferior version by default for a long time, just in case more testing is needed to discover problems in the release version (often in addition to multiple already discovered problems that Debian is intentionally leaving for users to suffer from, as the most natural way to fix them would be to update to a newer upstream version). Also, many things don't get separately packaged in experimental, like GDB 4.5 isn't (I don't know whether this particular case is due to release or maintainer otherwise not keeping it up to date, but there are lots of extra issues due to release, and most of them are unlikely to be because of maintainer being too busy with other release work). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1364816331.1928.103.camel@glyph.nonexistent.invalid
[OT] Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Hi all, while this thread may have the outcome of having Debian's R packages following a similar convention as with the perl-api package (why not, it does not seem to cost much), I hope that it is fairly clear for everyone that it will not change how we release or how we use experimental: this part of the thread is chatting, not focusing on getting something achieved. So please, let's use debian-devel for real attempts at developing Debian, not for chatting, however interseting it may be to those who do not mind reading long threads. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401120708.ge5...@falafel.plessy.net
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, 1 Apr 2013 17:42:29 +0600 Andrey Rahmatullin w...@wrar.name wrote: On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote: Thanks for trading the R release cycle with Debian's and for delaying the release. The harm has already been done, so somebody should probably go and create a transition tracker for it? Rather than accept the harm, surely the release team could simply roll back the upload in some manner? Only by uploading older versions with bumped version numbers, and that still will cause testing and unstable to have different binaries. That is why we have epochs - an epoch is ignored for the purposes of the binary packages, see zlib1g and other packages using epochs. The existing tools have sane support for epochs, exactly to avoid these problems. http://packages.debian.org/sid/zlib1g 1:1.2.7.dfsg-13 http://ftp.uk.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.7.dfsg-13_amd64.deb dpkg -l | grep ':' The version currently in wheezy could be re-uploaded with a single change to the changelog to start using an epoch and using the version string currently in wheezy for the post-epoch string of the new version. If wheezy had foo 1.2.3-1 and unstable 2.0.0-1, the epoch version of 1.2.3 would be 1:1.2.3-1 which is newer than 2.0.0-1 but be compatible with 1.2.3-1 already in wheezy. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpvkRP8x0Dof.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 01-04-13 13:38, Uoti Urpala wrote: Samuel Thibault wrote: Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit : Distributions that make latest software available are necessary for free software development. Again, that's one of the things experimental is for. It is not. You can't reasonably install things from experimental rather than unstable by default, Of course you can. Just add a file to /etc/apt/preferences.d that says Package: * Pin: release a=experimental Pin-Priority: 500 and packages will be pulled from experimental by default. Whether you'd want that is a different matter, of course. nor is there a flag for this really should be in unstable if not for badly managed release which would allow autoinstalling those packages. Consider the GDB example I mentioned earlier; GDB 4.5 should be installed by default for users of unstable, rather than expecting them to notice that their system has become too outdated, investigate it and find out which package to manually update. It is unreasonable to tell the users and upstreams that Debian is going to keep users on a known inferior version by default for a long time, No, that is not unreasonable. It is unreasonable to expect Debian will see the latest and greatest of everything at any given time. That is not our way. That's not to say that distributions which do such a thing are useless, or that their developers are idiots. They just have a different focus. You'll also see that once the freeze is over, newer versions will be uploaded, and this problem will be gone. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51597b8c.40...@uter.be
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote: It is not. You can't reasonably install things from experimental rather than unstable by default, nor is there a flag for this really should be in unstable if not for badly managed release I'm getting rather annoyed by this accusations of a badly managed release, and the continual diatrade from yourself blaming me and the rest of the release team. It is unreasonable to tell the users and upstreams that Debian is going to keep users on a known inferior version by default for a long time, just in case more testing is needed to discover problems in the release version (often in addition to multiple already discovered problems that Debian is intentionally leaving for users to suffer from, as the most natural way to fix them would be to update to a newer upstream version). You may consider it most natural, the rest of the project values stability and not introducing untested new features. Perhaps you may feel more at home in a different distribution which aligns with your priorities more. As it happens, I'm currently canvassing a release weekend when everyone who needs to do work on the day can make it. Messages such as the above do not help in any way, shape or form. Neil -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401120313.gm7...@halon.org.uk
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Hi, On Mon, Apr 01, 2013 at 11:47:10AM +0200, Samuel Thibault wrote: Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit : Distributions that make latest software available are necessary for free software development. Again, that's one of the things experimental is for. Which does not work either with a (almost) non-processed NEW. New software might need packaging changed and/or new libraries etc Regards, Rene -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401122658.gb31...@rene-engelhard.de
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, 1 Apr 2013 14:26:58 +0200 Rene Engelhard r...@debian.org wrote: Hi, On Mon, Apr 01, 2013 at 11:47:10AM +0200, Samuel Thibault wrote: Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit : Distributions that make latest software available are necessary for free software development. Again, that's one of the things experimental is for. Which does not work either with a (almost) non-processed NEW. New software might need packaging changed and/or new libraries etc ... and those uploads go into experimental as well. What's wrong with that? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpD1ZKeE6cUt.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 01:47:10PM +0100, Neil Williams wrote: ... and those uploads go into experimental as well. What's wrong with that? That non-processed NEW for packages which in turn is needed for other packages to go to experimental for getting them tested blocks those packages from being able to be uploaded/tested? If the time then comes when this all works out itself either the package gets delayed or it gets uploaded to unstable quite (it can be tested in experimental for those who use/want it) untested. (Or the packages itself being blocked, but that example was just uploaded on Thursday just before easter, so I understand it not being processed yet. Regards, Rene -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401125914.gc31...@rene-engelhard.de
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, 1 Apr 2013 14:59:14 +0200 Rene Engelhard r...@debian.org wrote: On Mon, Apr 01, 2013 at 01:47:10PM +0100, Neil Williams wrote: ... and those uploads go into experimental as well. What's wrong with that? That non-processed NEW for packages which in turn is needed for other packages to go to experimental for getting them tested blocks those packages from being able to be uploaded/tested? NEW processing happens whether the new package is meant for unstable or experimental. Whether the package is in unstable or experimental does not change how that package gets tested. It can affect how that package affects the release. 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. 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.) If the time then comes when this all works out itself either the package gets delayed or it gets uploaded to unstable quite (it can be tested in experimental for those who use/want it) untested. Compared to going into unstable completely untested directly from incoming? Packages don't go into testing directly from experimental, freeze or no freeze. Experimental packages get more testing than unstable, simply because the package has to go through unstable after the release anyway. At least the version you want tested is in the archive and it has no bearing on the release. During a release, maintainers need to take extra steps to not get in the way of the release: $ dch -D experimental -i the 'No RC bugs to fix' upload. Secondary to that, maintainers may also need to run debootstrap and manually tweak the apt config to pull in experimental as already described here by others. What's so hard about that with the R packages? We are trying to release, that means that *everyone* has some extra work to do either directly to help or at the absolute minimum to not get in the way of those who are helping. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpO6qIjDxKSJ.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 02:23:36PM +0100, Neil Williams wrote: NEW processing happens whether the new package is meant for unstable or experimental. Whether the package is in unstable or experimental does True. not change how that package gets tested. It can affect how that package affects the release. Yes, also true. 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. And testing is not only local machine but testing in experimental. (see above.) By *real usage*. (There have already been upgrade bugs found by people using my packages in experimental) 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*? And yes, I do people.debian.org. That's not the same as experimental. (E.g. builds on the majority of architectures will be untested. People will not look there, etc.) What's so hard about that with the R packages? Read and think again, please. 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. Regards, Rene -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401134644.ge31...@rene-engelhard.de
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 r...@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/ pgpGeao5XT9A8.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 03:36:35PM +0100, Neil Williams wrote: 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. This Debian. It is uninstallable there. And people (NOT ME!) can't install it. Which is the point. Or it even cannot be built. It defeats the purpose of experimental when someone who want to use a package from there need to go looking up some place where he can get the depencencies from. This is a RC bug the same way as it was in unstable or anywhere else. How trivial do you want it? How much do you want to go against Debians policies? 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 Obviously you didn't even dare to look. I was not making this up: http://ftp-master.debian.org/new.html 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. 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 So you uploaded non-bbuildab le, non-installable packages to experimental? Oh my. For your own repoitories you were right, but this is about Debian and it's distro. 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. [..,] 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. Obviously you can't read (or you don't want to, which this is more probable) but I am not talking abouut R but the general case. I highlighted it above again for you. Rgards, Rene -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401144226.gg31...@rene-engelhard.de
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, 1 Apr 2013 15:36:35 +0100 Neil Williams codeh...@debian.org wrote: On Mon, 1 Apr 2013 15:46:44 +0200 Rene Engelhard r...@debian.org wrote: Apologies Rene, got you mixed up with Dirk re the R packages. The bit about the epoch and the upload was intended for the R maintainers. On Mon, Apr 01, 2013 at 02:23:36PM +0100, Neil Williams wrote: 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? 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. It may require a little preparation, yes, but it clearly does work. 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. I'm going to stop here before I dig myself an even bigger hole... -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpaEPNz8fGSR.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Neil McGovern wrote: On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote: It is unreasonable to tell the users and upstreams that Debian is going to keep users on a known inferior version by default for a long time, just in case more testing is needed to discover problems in the release version (often in addition to multiple already discovered problems that Debian is intentionally leaving for users to suffer from, as the most natural way to fix them would be to update to a newer upstream version). You may consider it most natural, the rest of the project values stability and not introducing untested new features. I think you misunderstood that as saying I wanted to change packages in stable; the above was from the perspective of unstable (the natural way to fix known issues in unstable would be to upload a new upstream version). I do not believe there is any project-wide consensus to avoid newer versions in unstable. Perhaps you may feel more at home in a different distribution which aligns with your priorities more. I think unstable works reasonably well outside release problems (there are sometimes issues with new enough packages not being available, but I think those are mostly due to activity of individual maintainers, not project priorities). And I don't believe it to be a shared view of all Debian maintainers that only stable releases matter, and users of unstable are only tools to use to polish stable. Nor do I believe that all other users of unstable are only trying to help create stable releases for others to use, intentionally sacrificing their own experience to do so. And whatever distro I personally choose, as upstream of packaged software I certainly do not approve of Debian leaving its upstable users at a known inferior version during long release freezes. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1364827693.1928.122.camel@glyph.nonexistent.invalid
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, 1 Apr 2013 16:42:26 +0200 Rene Engelhard r...@debian.org wrote: On Mon, Apr 01, 2013 at 03:36:35PM +0100, Neil Williams wrote: 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. This Debian. It is uninstallable there. And people (NOT ME!) can't install it. Which is the point. Packages in experimental are installable for anyone using Debian, with the appropriate tweaks to apt config. Chroots and adapted apt config are perfectly acceptable for Debian - it's the established method of using experimental. Or it even cannot be built. Packages in experimental can be built trivially when the chroots used are also tweaked to see experimental. It defeats the purpose of experimental when someone who want to use a package from there need to go looking up some place where he can get the depencencies from. True but it can be useful in intermediate stages. However, I was only talking about uploading outside Debian as the last resort, not the recommended fix and certainly not making packages in experimental depend on external repos, that's the wrong way around. How much do you want to go against Debians policies? You're misunderstanding what I was trying to get at. Experimental is a suitable target for this work and when combined with unstable, it needs to be self-contained - correct. If a package in experimental needs a dependency, then that dependency upload also goes into experimental. The benefit is that if that goes wrong and the packages are uninstallable then first, that can be fixed in experimental and second, the RC bug does not affect the release (or other teams). 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 So you uploaded non-bbuildab le, non-installable packages to experimental? Oh my. No. Those I upload to personal reprepro instances, if at all. We're at cross-purposes here - I'm not advising uploading unfinished or interim/broken packages to experimental. However, merely using experimental for uploads during a freeze in no way makes an otherwise correct package uninstallable or FTBFS. r-deps are just a bit of extra work but that is *not* insurmountable. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgptgIfTlch86.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 05:48:13PM +0300, Uoti Urpala wrote: Neil McGovern wrote: On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote: It is unreasonable to tell the users and upstreams that Debian is going to keep users on a known inferior version by default for a long time, just in case more testing is needed to discover problems in the release version (often in addition to multiple already discovered problems that Debian is intentionally leaving for users to suffer from, as the most natural way to fix them would be to update to a newer upstream version). You may consider it most natural, the rest of the project values stability and not introducing untested new features. I think you misunderstood that as saying I wanted to change packages in stable; the above was from the perspective of unstable (the natural way to fix known issues in unstable would be to upload a new upstream version). I do not believe there is any project-wide consensus to avoid newer versions in unstable. http://wiki.debian.org/DebianStability. Also see dev-ref 3.1. And the huge amount of discussion that lead to http://wiki.debian.org/ReleaseProposals in 2005. As for consensus, have a read over this thread to see if there's anyone supporting your views. Perhaps you may feel more at home in a different distribution which aligns with your priorities more. I think unstable works reasonably well outside release problems (there are sometimes issues with new enough packages not being available, but I think those are mostly due to activity of individual maintainers, not project priorities). And I don't believe it to be a shared view of all Debian maintainers that only stable releases matter, and users of unstable are only tools to use to polish stable. Nor do I believe that all other users of unstable are only trying to help create stable releases for others to use, intentionally sacrificing their own experience to do so. And whatever distro I personally choose, as upstream of packaged software I certainly do not approve of Debian leaving its upstable users at a known inferior version during long release freezes. Wow. I would have liked to find a source in dev-ref or something which pointed out explicitly the commitment to releases. But I can't because we've been doing releases for NEARLY 20 YEARS. You seem to believe that unstable is more important than stable releases. I do not. One of us is in the wrong project. Neil -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401154519.gn7...@halon.org.uk
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Hi, On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote: On Mon, Apr 01, 2013 at 05:48:13PM +0300, Uoti Urpala wrote: You seem to believe that unstable is more important than stable releases. I do not. One of us is in the wrong project. That's easy to answer: It must be you, because Uoti Urpala does not appear to be a DD or DM, AFAICT. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401162512.ge23...@nighthawk.chemicalconnection.dyndns.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, 31 Mar 2013, Dirk Eddelbuettel wrote: It really does not add much as well already have a, say, Dependds: r-base-core (= 3.0.0~20130327) so we are really just trading one for the other as far as I can tell. The difference is that you can do the following: r-base-core Provides: r-base-api-3 and all cran depends on r-base-api-3. When the API changes incompatibly, and an entire rebuild is required, you change the api, so that r-base-core now Provides r-base-api-4. Now, all cran packages have to be upgraded in lockstep with R, and you cannot have R packages installed which are incompatible with the R interpreter. The version number attached to the API only increments when the API changes incompatibly. If the API changes in a complex way, you could also conceivably provide multiple versions of the API in the base package. Don Armstrong -- Tell me something interesting about yourself. Lie if you have to. -- hugh macleod http://www.gapingvoid.com/archives/batch20.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401165451.gy4...@rzlab.ucr.edu
