Re: Bits from the Security Team
Didier 'OdyX' Raboud wrote...
> I, for one, have been routinely dropping transitional binary packages
> that were in the latest stable; they were needed to migrate from (the
> releases which are now) oldstable to stable but are only archive noise
> now. Delaying that cleanup for an additional stable release cycle really
> feels like unnecessary delay, during which we pretend to maintain code
> that hardly anyone tests.
The missing tests are indeed a problem. For migration code in
(usually) postinst or transitional packages I don't see the big issue,
besides a maintainer's notion of "I'd like to get rid of that old
stuff".
Face the fact: Users *will* skip upgrade from squeeze-lts to (then
stable) jessie, you cannot bar them from doing this. If they break
their system, any "That was not supported, told you so" is not
helping, neither them nor Debian's reputation. Better support such
upgrades from the beginning.
So I was thinking whether there was a way packages that do not support
skip upgrade may enforce an upgrade path via the intermediate
distribution. First idea was a new Pre-Conflicts: package
relationship, then I was wondering whether it shouldn't be simply
possible to write (for a package in jessie):
Package: foo
Conflicts: foo (<< $[wheezy-version]~)
But Policy 7.4 has the answer, it's "no".
Assuming we could somehow turn off that exception, a skip upgrade is
impossible for that package, but it's blocked /before/ things break.
The solution for the user then was to add the skipped release to
sources.list temporarily, and go on. The search engines soon will
learn that trick from the first bug reports, and users can find it
using the specific error message they see.
Benefit: Only the packages that do not support skip upgrades will need
that step, also reducing bandwidth usage and walltime needed for the
skip upgrade.
> The problem is that there is no policy in place to make us support
> oldstable-to-testing upgrades. If there's interest, that'd need to be
> decided with a more firm policy than "encourage maintainers".
Would you have preferred to read something "putting the burden onto
the maintainers"?
Christoph
Reply to: