Re: A concrete proposal for rolling implementation
Josselin Mouette <firstname.lastname@example.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 for each arch.
 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
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.