[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Transition control


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.


[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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: