Re: A concrete proposal for rolling implementation
Le mercredi 04 mai 2011 à 15:30 +0200, Raphael Hertzog a écrit :
> On Wed, 04 May 2011, Josselin Mouette wrote:
> > It starts from the following fact: if you want a testing system that
> > works correctly, you usually have to add APT lines for unstable, while
> > pinning them to only install specific packages you need to unbreak
> > what’s broken in unstable.
>
> I think you meant "what's broken in testing" (i.e. you take a few selected
> packages from unstable to fix bugs present in testing).
Yes, of course.
> 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.
> 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.
> > The rolling suite would only exist for a subset of architectures (we
> > could start with powerpc, i386 and amd64), generated by picking up
>
> Why powerpc? If we really take more than i386/amd64 for rolling, there are
> more users of armel than of powerpc.
Yes, sure. It was just an example.
> 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.
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.
> 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.
--
Joss
Reply to: