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, so it is available immediately. Simon  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.
Description: OpenPGP digital signature