On Thu, May 01, 2014 at 05:29:39AM +0200, Guillem Jover wrote: > On Wed, 2014-04-30 at 15:28:27 +0200, Johannes Schauer wrote: > > Quoting Johannes Schauer (2014-04-26 07:15:03) > > > Because of this syntax change, packages that use this syntax can only be > > > uploaded once tools in Debian stable support it because the build > > > infrastructure runs Debian stable. > Much of our infrastructure code comes from unpackaged projects (?), > which makes this an awkward requirement, I guess it's the price of > reusing existing packaged code by the unpackaged projects. :/ There is a general problem that you want to make changes and you have only one live host where the software is primarily run. Or it does not support upgrades properly. (Sort of true for wanna-build; even though there are people trying to run it separately — like d-p.o —, but it is painful.) For sbuild and buildd, they are actually packaged and available on https://buildd.debian.org/apt/ but they are forked because we need to be able to be on a stable codebase and be able to make changes quickly on top of that. Maintenance of buildd in unstable is tied to sbuild and stuff tended to break too often. It's hard to tie our cycle to backports which relies on testing migration of newer versions in unstable that were never even smoke-tested for our use. It's kind of a chicken-egg problem on how to bootstrap package use in absence of regression tests. I'd be very nice but I don't see how that'd work with the kind of policies we have. Any urgent change would still require a repo to push from to all the buildds, for instance. > In this case one would have expected to be able to use build profiles > right away after the required infra changes (at least I think it > would have been possible in the past?), because they don't affect the > dist-upgrade path, but it seems there's new restricting factors now. I don't think the requirements for stable updates were any more lax in the past (in fact they were much stricter), or that people were more tolerant to do incompatible changes. There was, as far back as I remember, always the notion that things need to land in stable before they can be used. dist-upgrade path was a primary motivator, but handling of packages, even source packages, with stable tooling, was as important. See things like xz compression where we also needed to wait. Kind regards Philipp Kern
Attachment:
signature.asc
Description: Digital signature