On Fri, 10 May 2013 11:24:30 +0200 Ivo De Decker <ivo.dedecker@ugent.be> wrote: > Hi, > > On Wed, May 08, 2013 at 05:28:58PM +0100, Neil Williams wrote: > > Other steps to take as preventative measures: > > > * Make it a *MUST* that all transitions, no matter how small, are > > checked with the release team starting from as soon as the freeze is > > announced (not just after it starts) such that uploads which start a > > transition could be pushed into DELAYED or REJECTed automatically. (Not > > easy to implement this one, I know.) > > This could be implemented by building uploads to unstable against testing > instead of unstable. The whole point with a transition is that a library is updated in unstable and, for the updated library to migrate, it's reverse dependencies in unstable need to migrate to that updated library by being built against the version of that library in unstable. Otherwise, migration is blocked because reverse dependencies already in testing become uninstallable. There may be source code changes required in those reverse dependencies. There needs to be time for this to happen and then for all affected packages to migrate. There's no point building packages against testing as, at the critical stage, the version of the library to which the packages are meant to transition is *not* in testing. If those reverse dependencies are to be rebuilt at all, the rebuild needs to happen against the version which is trying to migrate - the one in unstable. Packages don't get rebuilt in testing - rebuilds go back through unstable. Problems arise from the number of reverse dependencies and when transitions get blocked by other transitions because of some packages which depend on two or more libraries already involved. Rebuilding any of those against testing is pointless - the packages need to be rebuilt against the new versions in unstable and, where necessary, migrated to the updated API. Prior to those rebuilds, the affected packages in testing and unstable were likely last built against the version of the library already in testing - I see no point in building them again for the same version. We have that build, it's that build which needs to be replaced by a build against the version of the transitioning library in unstable. > Currently problematic uploads to unstable don't affect users of testing > because they will not migrate, but they do affect development of testing > (which is done in unstable), because they will prevent reverse > build-dependencies from migrating. The point is to keep testing installable, not to allow updated applications into testing without having a transition at all. The applications must transition and that must happen in unstable if testing is to remain installable. There is no point allowing applications using libfoo0 already in testing to be rebuilt against libfoo0 (which no longer exists in unstable) when the whole point is that it is the lack of a build of the applications against libfoo1 which is blocking the migration of those applications *and* libfoo1 into testing. Any update, any new version of those applications, needs to be built against libfoo1, the version in unstable. There would be no libfoo1 in testing and no libfoo0 in unstable. The exceptions to this are libraries which use the libfoo0-dev mechanism, generally because there are so many reverse dependencies that both versions need to exist not only in unstable but in testing and stable too - think libgtk2.0-0 and libgtk3.0. That requires new source packages for every SONAME change - something which is only worth doing for packages like GTK. > If uploads to unstable were built against testing, uncoordinated uploads of > build-dependencies would not affect development, because they would not be > used by the autobuilders until they were allowed to migrate to testing. They > would still be used (and tested) by developers running unstable on their > systems. What builds the packages in unstable? I think you're only considering a single architecture. Even just thinking of x86, there are just as many i386 uploads as amd64 - something has to build amd64 uploads for i386 in unstable and vice versa. Those builds need to be against the versions of dependencies in unstable - that is the job of the autobuilders. Developers can't run unstable if there are no builds other than uploads and unstable isn't just about x86 anyway. Even if the intent is to rebuild uncoordinated uploads of applications which would inadvertently tie two different transitions together, I see no gain over simply waiting until the transitions are complete before making the upload. If you build against the version in testing, the application will then have to be rebuilt against the version in unstable before the application can migrate anyway. Where is the advantage? If you allow the application to migrate, it will still have to transition to the new library before the library itself can migrate. So instead of one rebuild, you now have three. How does that help anyone? -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgplEVMzaQ6jC.pgp
Description: PGP signature