Re: A concrete proposal for rolling implementation
On Wed, 04 May 2011, Josselin Mouette wrote:
> > It doesn't need to be a pseudo-suite. It's a collection of packages taken
> > in testing or unstable, it's not more complicated to make it a full suite.
>
> It cannot be “just” a full suite. When you add a package coming from
> unstable, you must also keep the version that is already in testing. To
> follow on my example, if you allow libgnomekbd and gnome-settings-daemon
> from unstable, you still need libgnomekbd from testing, otherwise other
> packages will become uninstallable.
A full suite can have 2 versions of the same source package and
can contain both libgnomekbd4 and libgnomekbd7. It's not a problem.
> > And PR-wise, it's way better to avoid "testing" appearing in the
> > sources.list.
>
> That’s really an implementation detail. If you really want to hide it,
> you just need to ensure rolling can have two versions of the same
> sources at the same time.
OK. Testing already can, so it should be ok for rolling too.
> > You still need some sort of britney to verify that the package is effectively
> > installable in rolling, and to verify you're not breaking installability
> > of other packages available in rolling.
>
> If rolling is just an overlay on testing, I don’t think that’s
> necessary. The worst that could happen is that the version in rolling is
> uninstallable, but the version in testing would still be.
Yes but as long as it's uninstallable, the bug is not fixed for the user.
So while we did not break anything, we did not fix anything either.
:-)
> What the britney-like thing could do is bring automatically all
> dependencies that are actually necessary for the package to be
> installable. But this could also make things more complicated, since
> britney tests source packages, not binaries. You might bring a source in
> rolling only for a runtime that is needed, but the development header
> being uninstallable is not a problem. Britney would prevent that, while
> it would still be a good move.
Yes, we could try to improve britney towards this.
But I'm not sure it's a good idea to pick only some binary packages from a
source package. It happens often enough that the package lack a strict
dependency that might be required and picking all the binaries from a
source package limits the risk of upgrading them separately (and thus
experiencing the bug).
> > Once we diverged from testing, there's the question of what to do when the
> > package gets updated in unstable. By default the answer is "nothing"
> > unless the updated package fix a RC bug that is not present in testing
> > but that was introduced since then (and is now present in the rolling
> > version).
>
> I’m not entirely sure, but I think it’s better to pick the update from
> unstable instead of letting in rolling a package that is no longer
> available somewhere else. It should make upgrades smoother, and it
> should also be less work for maintainers, since it avoids having another
> version from which problems can arise.
In that case, those updates should follow the same rules than for testing
itself. It would be unreasonable to accept the new unstable upload
immediately.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: