Re: An old idea, brought back to life
On Sun, Dec 27, 1998 at 01:08:08PM +1000, Anthony Towns wrote:
> I greet you, Sir, and you, humble followers of this mailing list, with
> salutations and the best wishes of the season,
Cheers.
[deletia]
> Okay, the prerelease proposal wasn't intended to help or hinder those
> goals. It's major purposes was to make it so we could make releases
> when we wanted to, rather than having to havecontinually have extended
> freezes while we wait for the last few bits of a release to come together.
I think that these problems are linked.
> But anyway...
>
> > The second problem is due to the fact that we cannot presently install
> > systems that are partially in one distribution and another. For
> > example, we cannot easily mix potato and slink when there are
> > conflicting library updates.
>
> Library updates should only conflict if there's no possible way around it.
> The only times that doesn't work is when maintainers make mistakes or bad
> decisions. Since we're not perfect, there's not much we can do to stop
> this, so working around it's the only real option.
>
> And since we've got a fairly good dependency system, that's not too
> much of a problem. If you want to install the new libc6 from unstable,
> all you need to do is add:
> deb http://foo/debian unstable main
> to apt/sources, run apt-get update, and apt-get install libc6.
Well sort of. There was the case previously where we had to replace
once version of libc5 with another so that libc6 could be introduced.
I believe this happened when we went from hamm to slink. I believe it
prudent to expect this sort of thing to happen again since...we don't
know if we'll need to.
> Everything it depends on (or depends on it in a versioned way) gets
> updated, nothing else does, and you're happy.
Apt appears to be good about this, yes.
> What we don't have is some way to revoke that decision, say "Okay, that
> was fun, but I want to go back to frozen. Buggy junk", and downgrade
> the packages you just installed to ones that work. The new Apt UI may
> have some support for this, but I'm not sure. (I'm not quite sure what
> the UI-doc means when it discusses this functionality)
>
> In any case, this requires changes to the tools, not the ftp site, afaict.
> I've no doubt that the Apt team would appreciate a hand with the coding
> of said tools, either.
Sorry, but everyone makes this plea. While I don't expect my ideas to
be implemented without putting sweat behind them, I think it is
important to be open to discussion.
So, let's start with the archive reorg. You say the the reason for
reorg is that we need to be able to release more frequently and with
greater confidence than we presently have. I assert that the testing
loop is a crucial weakness in this plan. If we implement the
prerelease idea such that it is a separate dist the way that
frozen/stable/unstable are, then we don't have a practical method for
testing. For example, "I want to see if the latest Emacs fixes bug
#8....Oh, it does but it also breaks this other thing...I report
it...downgrade...and continue on my way." Or imagine that I have a
box used for automated testing where I install a series of predefined
configurations and run a battery of tests. If a particular setup
fails because one component is faulty I may lose the whole kit and
kaboodle. If, however, I can downgrade a couple of miscreants then I
can verify a subset.
Otherwise, if I have to install prerelease and then test and then
perform another test after it migrates to stable (to see how it
interacts there) I'm now obliged to run twice as much testing....my
original critique.
I would say that without the ungrade/downgrade changes, the changes to
the archive have little significance. We need the testability before
we can decide intelligently when to move packages from prerelease (or
whereever) to stable (or whereever).
Cheers.
Reply to: