Re: How to update Debian 11 source.list to testing?

[Roberto C. Sánchez]

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.

You might consider using bookwork rather than testing, however. That is
the name of the testing release and unless you specifically want to
continue tracking testing even after bookwork is released, it is
probably better for most use cases to use the specific release code name
rather than stable or testing.

Regards,

-Roberto

--
Roberto C. Sánchez

[Richard Forst]

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?

Thanks

[The Wanderer]

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?

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 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.

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.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Roberto C. Sánchez]

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.

[piorunz]

On 03/09/2021 15:17, Roberto C. Sánchez wrote:
> If you change all instances of bullseye -> testing, then you are not

> mixing. Go ahead with that (...)

Yep, that's all there is to say. testing word instead of bullseye
everywhere in sources.list will do the trick.

AFAIK, you may also disable "-security" entry, as testing doesn't have
dedicated security team and testing-security repository will be empty.

--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[Roberto C. Sánchez]

On Fri, Sep 03, 2021 at 04:25:39PM +0100, piorunz wrote:
> On 03/09/2021 15:17, Roberto C. Sánchez wrote:
> > If you change all instances of bullseye -> testing, then you are not
> > mixing. Go ahead with that (...)
>
> Yep, that's all there is to say. testing word instead of bullseye
> everywhere in sources.list will do the trick.
>
> AFAIK, you may also disable "-security" entry, as testing doesn't have
> dedicated security team and testing-security repository will be empty.
>

I actually would recommend leaving it. In the last months prior to the
next release, particularly when the freeze goes into effect, there will
be uploads into bookwork-security (or testing-security). It doesn't
hurt anything to leave it.

[Eduardo M KALINOWSKI]

But there's a chance that the version in stable is not installable
anymore because it depends on packages that have been upgraded on
testing and are incompatible with stable.

That said, I agree with you that there's a bit of exaggeration about
mixing releases. Sure, it's not something to be recommended to a
beginner or someone who's used to just clicking "Next >" to
install/upgrade software, but provided one knows what they are doing and
are careful when running apt-get (or equivalents), it's certainly
possible and won't lead to guaranteed breakage.


--
Goes (Went) over like a lead balloon.

Eduardo M KALINOWSKI
edu...@kalinowski.com.br

[Greg Wooledge]

On Fri, Sep 03, 2021 at 10:40:32AM -0400, The Wanderer wrote:

> 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 [...] there have been some problems [...]

This is *precisely* why we advise against doing this. A dedicated
expert in Debian may be equipped to handle the problems that arise.
If you think you're good enough, and you want to do this, we can't
stop you. But we also can't help you when it breaks.

[Brian]

On Fri 03 Sep 2021 at 10:40:32 -0400, The Wanderer wrote:

[...]

> Are you sure about that last part?
>
> 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 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.
>
> 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.

Surely - if you have a package installed from a previous release,
it does not get removed simply because testing does not have it?
It looks to me that the first line in sources.list does not help
in this situation.

--
Brian.

[Greg Wooledge]

On Fri, Sep 03, 2021 at 06:24:31PM +0100, Brian wrote:
> On Fri 03 Sep 2021 at 10:40:32 -0400, The Wanderer wrote:
> > deb http://ftp.us.debian.org/debian/ stable main non-free contrib
> > deb http://ftp.us.debian.org/debian/ testing main non-free contrib

> Surely - if you have a package installed from a previous release,
> it does not get removed simply because testing does not have it?

Correct.

> It looks to me that the first line in sources.list does not help
> in this situation.

Also correct, *but* it does help if you want to install something from
stable that has been removed from testing.

In the absence of "pinning", using the two lines that The Wanderer
posted would give you a testing system, with the option to pull in
packages from stable if needed. It's a viable setup. Sensible.

The problem is, sometimes people think it's the opposite of that.
They think they can run a "mostly stable" system with the option to
cherry-pick packages from testing. This is *NOT* the case. And no
amount of "pinning" will make it so.

(If you actually want such a system, use stable-backports. That's
what they're for. Do not pull binary packages from testing. I know,
we say this every 3 days, but that's because the issue *comes up*
every 3 days. We can't stamp it out.)

[The Wanderer]

While I acknowledge the points raised thus far (that being why I haven't
responded, since I wouldn't have had much to say but "That's fair"), I
don't think this is entirely right. You snipped out the part where I
pointed out that as far as I can tell, the problems which I had are the
same ones which I'd have had from just tracking testing anyway. If
that's correct, then the fact of tracking both will have had nothing to
do with my having encountered those problems.

[The Wanderer]

On 2021-09-03 at 13:40, Greg Wooledge wrote:

> On Fri, Sep 03, 2021 at 06:24:31PM +0100, Brian wrote:
>
>> On Fri 03 Sep 2021 at 10:40:32 -0400, The Wanderer wrote:
>>
>>> deb http://ftp.us.debian.org/debian/ stable main non-free
>>> contrib deb http://ftp.us.debian.org/debian/ testing main
>>> non-free contrib
>
>> Surely - if you have a package installed from a previous release,
>> it does not get removed simply because testing does not have it?
>
> Correct.
>
>> It looks to me that the first line in sources.list does not help in
>> this situation.
>
> Also correct, *but* it does help if you want to install something
> from stable that has been removed from testing.

Yep - and that's the main reason why I keep this arrangement.

> In the absence of "pinning", using the two lines that The Wanderer
> posted would give you a testing system, with the option to pull in
> packages from stable if needed. It's a viable setup. Sensible.
>
> The problem is, sometimes people think it's the opposite of that.
> They think they can run a "mostly stable" system with the option to
> cherry-pick packages from testing. This is *NOT* the case. And no
> amount of "pinning" will make it so.

I hadn't even considered that angle, although now that it's been brought
up I recall having seen it discussed in the past.

No, indeed - that's not going to work, and it should not be anything
close to recommended. I would not want my description of my own setup to
be interpreted as an endorsement of trying to do that.

[Brian]

On Fri 03 Sep 2021 at 13:40:52 -0400, Greg Wooledge wrote:

> On Fri, Sep 03, 2021 at 06:24:31PM +0100, Brian wrote:
> > On Fri 03 Sep 2021 at 10:40:32 -0400, The Wanderer wrote:
> > > deb http://ftp.us.debian.org/debian/ stable main non-free contrib
> > > deb http://ftp.us.debian.org/debian/ testing main non-free contrib
>
> > Surely - if you have a package installed from a previous release,
> > it does not get removed simply because testing does not have it?
>
> Correct.
>
> > It looks to me that the first line in sources.list does not help
> > in this situation.
>
> Also correct, *but* it does help if you want to install something from
> stable that has been removed from testing.
>
> In the absence of "pinning", using the two lines that The Wanderer
> posted would give you a testing system, with the option to pull in
> packages from stable if needed. It's a viable setup. Sensible.

The bit that neeeds emphasising is

...give you a testing system.

That is what the second entry in sources.list does.

It doesn't matter what the other line is, the user is working
with a testing system. That is where the packages come from.

Having said that, the option to pull in packages from stable
as needed is moot, apart from security updates or absence on
testing. It looks like cargo cult.

--
Brian.

[The Wanderer]

Absence in testing is the specific reason why I still include that line:
in case I need to install a package because I need its functionality,
but it's been temporarily removed from testing for whatever reason.

That scenario has actually arisen a handful of times over the years, and
the rest of the time, having the line included doesn't seem to have done
any harm.

[riveravaldez]

On 9/3/21, The Wanderer <wand...@fastmail.fm> wrote:
> On 2021-09-03 at 15:16, Brian wrote:
>
>> On Fri 03 Sep 2021 at 13:40:52 -0400, Greg Wooledge wrote:
>>
>>> On Fri, Sep 03, 2021 at 06:24:31PM +0100, Brian wrote:
>

>>> (...)

>>> In the absence of "pinning", using the two lines that The Wanderer
>>> posted would give you a testing system, with the option to pull in
>>> packages from stable if needed. It's a viable setup. Sensible.

>> (...)

>
> Absence in testing is the specific reason why I still include that line:
> in case I need to install a package because I need its functionality,
> but it's been temporarily removed from testing for whatever reason.
>
> That scenario has actually arisen a handful of times over the years, and
> the rest of the time, having the line included doesn't seem to have done
> any harm.
>
> --
> The Wanderer

In fact, I'm just right now dealing with kinda situation.

There's this `phwmon.py`[1] which I use with fluxbox to have a couple
of system monitors at hand, and that depends on some python2 packages.
I've just made it work, installing manually (# apt-get install packages.deb)
this packages that I've downloaded from OldStable official archives:

python-psutil
python-is-python2 (this is in fact in Testing)
python-numpy
python-pkg-resources
python-cairo
libffi6
python-gobject-2
python-gtk2

Therefore, my question:

Is it better to install them as I did, or adding the line in sources.list as
The Wanderer does?

Thanks a lot in advance.
Kind regards!

[1] https://gitlab.com/o9000/phwmon

[Richard Forst]

I will change to testing with all keyword switched to testing because my case is more often needing to use newer version software compared to stable, which also works fine w/t a problem for most of time.

Thanks for all your help, and advice! Appreciate it!


Sep 4, 2021, 09:30 by riverava...@gmail.com:

[Richard Hector]

On 4/09/21 2:17 am, Roberto C. Sánchez wrote:
> You might consider using bookwork rather than testing, however.

Or bookworm, even.

Richard

[Andrew M.A. Cater]

Small thing: the release that should eventually become Debian 12 - that is
currently also referred to as testing is bookworm NOT bookwork.

Given that even the CD release team were consistently mistyping it - and
mental autocorrect will change it automatically - that's unsurprising.

In general: referring to current/future releases by codeword is a good
thing - it does keep you consistent.

Mixing releases is having concurrent lines for stable AND testing in the
same file (also testing and unstable). It's not a real sin, but you have to
know which bits come from where and how to resolve breakages. With the
passing of time, you're more or less guaranteed to be running testing in
that scenario anyway.

https://wiki.debian.org/DontBreakDebian is relevant here to most people
who would want to install a random .deb from a third party vendor or
random website.

All the very best, as ever,

Andy Cater