Re: How to update Debian 11 source.list to testing?
On Fri, Sep 03, 2021 at 10:40:32AM -0400, The Wanderer wrote:
> On 2021-09-03 at 10:17, Roberto C. Sánchez wrote:
>
> > On Fri, Sep 03, 2021 at 04:11:49PM +0200, Richard Forst wrote:
> >
> >> I just installed Debian using netinstall image. I thought I install
> >> testing version, but apparently it's Debian 11. So now my
> >> source.list looks like below:
> >>
> >> deb http://deb.debian.org/debian/ bullseye main non-free contrib
> >> deb-src http://deb.debian.org/debian/ bullseye main non-free contrib
> >>
> >> deb http://security.debian.org/debian-security bullseye-security main contrib non-free
> >> deb-src http://security.debian.org/debian-security bullseye-security main contrib non-free
> >>
> >> deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
> >> deb-src http://deb.debian.org/debian/ bullseye-updates main contrib non-free
> >>
> >> I want to switch to testing version. In the past I just change the
> >> keyword from e.g. bullseye to testing, and generally there is no
> >> weird problem. But I read on the internet saying that the
> >> source.list should not mix up with different version. For instance,
> >> Debian 11 with testing. So I am wondering if there is a better way
> >> to switch to testing? Or reinstalling is the only way to go?
> >
> > If you change all instances of bullseye -> testing, then you are not
> > mixing. Go ahead with that, modulo the standard caveats associated
> > with running testing. The problem would come if you tried to include
> > both bullseye *and* testing sources in your sources.list. Then you
> > might create very difficult to resolve problems.
>
> Are you sure about that last part?
>
Yes, I'm sure, that's why I used *might* :-)
> I have been running with (e.g.)
>
> deb http://ftp.us.debian.org/debian/ stable main non-free contrib
> deb http://ftp.us.debian.org/debian/ testing main non-free contrib
>
> for over a decade, and while there have been some problems, I think
> they've been basically the same ones I'd have seen from running testing
> alone; none of them have seemed terribly difficult to resolve, either.
> (At least not by my standards, although I'll admit that I may not be the
> best or most representative example.)
>
I respect your experience as valid. However, the anecdotal "I haven't
experienced this particular problem" does not automatically extend to
"therefore nobody else should either". The people who have written the
documentation have provided a great deal of user support over the years.
It seems unlikely that they would invent phantom problems to try to
frighten users. Having experienced problems precisely as those
described associated with mixing releases, I can testify to the fact
that it can happen.
> I don't particularly consider this mixing releases; it's more tracking
> testing, while still keeping available any packages which were in stable
> but have been removed from testing.
>
Yet, the further way the stable release becomes from the present, the
greater the divergence of things like library dependencies. It is, in
fact, mixing releases. Depending on which particular set of packages
you have installed, you might see no problems, only minor problems, or
extraordinarily difficult problems. Hence, the caution.
> IMO, if you're going to track testing at all on a production computer
> (as opposed to, well, for the purpose of actually *testing the upcoming
> release*), it only makes sense to also include stable; there's too much
> chance of an important package being (temporarily or permanently)
> unavailable, otherwise.
>
Note that the OP's concern was "I want to switch a just-installed system
from bullseye to testing, but I'm concerned about mixing releases." The
idea is that if everything is switched from bullseye to testing then it
isn't mixing releases. However, I did feel the need to point out the
nature of potential problems to be encountered.
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: