Re: 3.13.0 kernel package not available in wheezy-backports
> Wait a bit until the linux* packages are accepted from backports NEW:
> https://ftp-master.debian.org/backports-new.html
This seems to be an on-going problem in backports -- packages can be
uploaded and accepted and we end up with lots of uninstallable packages for
a period of either because the arch:all packages appear instantly and the
arch-specific packages take days to appear or because the uploader made a
mistake and forgot to also upload build-deps or dependencies.
We spend a lot of effort ensuring that stable releases don't have
unsatisfied dependencies and are self-hosting. Users of stable never need to
experience such ugliness and it would be preferable not to inflict it on
users of backports either. We even insulate the testing suite from such
vagaries with the unstable suite and migration routines that, unless force
is applied by a release manager, don't allow testing to get into an
inconsistent state. However, the backports archive is exposing users of
stable to exactly the sorts of problems that users of testing would never
see -- missing packages and unsatisfiable dependencies.
In particular, backports needs to:
* catch unsatisfiable build-deps before they hit the archive
* catch unsatisfiable dependencies before they the archive (this includes
making arch:all packages wait for arch:any packages to be ready as well as
dependencies that are simply wrong because the package doesn't exist or the
version constraint is not satisfiable)
We already have the technology to ensure that a suite is self-consistent and
this looks like precisely the sort of job that a computer will do better
than a human. Have we reached the stage where the backports archive is
sufficiently large and complex that it needs its own staging area with a
tool like britney or edos only permitting packages in that are actually
ready? (and the natural follow-up question is, how can this be done?)
cheers
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ stuart@nanonanonano.net
Debian Developer http://www.debian.org/ stuart@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Reply to: