On Tue, 3 Aug 2010 17:18:17 +0200 Jeffrey Ratcliffe <[email protected]> wrote:
> squeeze has libforks-perl 0.33-1, which seems to build OK. If 0.34-1 > doesn't build cleanly on all architectures, then it won't move to > testing, but surely the version in testing has no RC bug and can > therefore stay? > > Or have I misunderstood things? 1. libforks-perl has FTBFS in previous versions on armel - rolling back is not necessarily going to fix the bug. (There is a reasonable chance that the test suite failures in other releases were still present in the version in squeeze, just didn't show up in that particular build.) 2. if libforks-perl is a drop-in replacement (as described) for the internal perl threading support, it isn't (or shouldn't be) a big change to revert to that support. (If it is, maybe that indicates that gscan2pdf itself has unresolved issues in it's own use of threads.) 3. Packages don't move from testing into unstable. Rolling back is not fixing the bug, it's just working around it. That isn't good enough for stable. 4. libforks-perl isn't in stable, why shouldn't gscan2pdf revert to the perl threads support in stable? 5. This is only about the Squeeze release. If libforks-perl upstream manage to fix the problems (which, as above, are NOT exclusive to the current version in unstable), both packages can be reintroduced after the release. 6. Only gscan2pdf requires libforks-perl. You've already described that gscan2pdf uses a dependency which is not threadsafe inside a threaded environment. Insisting on keeping libforks-perl merely for one application which itself has design issues around threads is not a recommended negotiating position. Such requests are likely to reinforce the perception that gscan2pdf itself should be removed alongside libforks-perl. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpaoVQuQgJOW.pgp
Description: PGP signature
