Hi,
Eduard Bloch schrieb:
> Yep. What about another crazy idea... why not check the expected impact
> from a certain package update before a package has been accepted in
> _Unstable_? So katie could just veto a version change automaticaly
> before it too much mess is created, even (or especially) in Unstable.
How about doing that via the autobuilders and experimental? I've been
thinking about it for some time, and my proposal would be (indentation
added for clarity):
for each package
that build-depends on a package
that is also in experimental and
that would no longer be installable would
the package in experimental move into unstable
(i.e. the source of the package in experimental no longer builds a
binary package required by the package in unstable or the package in
experimental actively conflicts with the package in unstable),
the autobuilders rebuild
the package in unstable against
unstable plus
those packages
that break the package
in unstable
taken from experimental,
versioned as a binary NMU above
the version in unstable and
upload to experimental.
Example (for extended clarity):
kfoo 1 depends on libkde1
kde 2 enters experimental, no longer builds libkde1 but still provides
libkde-dev. The autobuilders notice that moving kde 2 to unstable would
remove libkde1 as it is no longer built, hence kfoo 1 became
uninstallable. Thus, kfoo is rebuilt as version 1.0.1 and uploaded to
experimental. When kde 2 enters unstable, kfoo 1.0.1 can then be taken
from experimental[1], so it is available immediately.
Simon
[1] it needs to be checked whether it would be good to automatically
rebuild such packages whenever a new libkde2 appears in experimental, so
things do not break when libkde2 accidentally changes ABI while in
experimental.
Attachment:
signature.asc
Description: OpenPGP digital signature