Re: A concrete proposal for rolling implementation

[Ansgar Burchardt <ansgar@mathi.uni-heidelberg.de>]

Hi,

Josselin Mouette <joss@debian.org> writes:
>   The new “rolling” suite
>   -----------------------
> This would be a pseudo-suite, like experimental. Except that while
> experimental is built on top of unstable and filled manually by
> maintainers, rolling would be built on top of testing and filled
> semi-automatically. A rolling system would have typically 2 APT lines:
> one for testing and one for rolling.
>
> The rolling suite would only exist for a subset of architectures (we
> could start with powerpc, i386 and amd64), generated by picking up
> packages from unstable. Typically it would be generated from an override
> file that looks like:
> source-package version
> xserver-xorg-video-ati 1.2.3-4

I don't think this needs to be restricted to a subset of architectures
when you allow "rolling" to pick different versions[1] for each arch.

  [1] including none if the required version is not available in unstable

>   A concrete example
>   ------------------
> Let’s imagine something that might happen soon (although of course we
> will try hard for it not to happen): a new version of nautilus migrates
> to testing, but it was missing a Breaks - it doesn’t work with the
> version of gnome-settings-daemon in testing. The new
> gnome-settings-daemon in unstable works, but it won’t migrate because
> there is a libgnomekbd transition in progress, and gnome-screensaver
> which is part of the transition doesn’t build on s390.
>
> In this case, we can just add libgnomekbd and gnome-settings-daemon to
> the override file. Users of the rolling suite will have the two versions
> of libgnomekbd available, and they can update their systems to a working
> state.

In this case, you could add the newer version to "rolling" for all
architectures except s390.  This way all users not using s390 could
already upgrade to the new version.

Ansgar