Welcome to SparkyLinux forums
Zapraszamy również na polsko-języczne Forum

Making choices on old repositories

Started by kendew, March 29, 2020, 01:11:16 AM

Previous topic - Next topic


I picked up a laptop that had Sparky 5.7.1 Testing version installed some half year ago.  The laptop had been sitting in storage but recently in demand because students want them for online study during corona virus closing schools.  I attempted to upgrade the system in the terminal with apt update to get it ready and was shown this:

QuoteGet:1 testing InRelease [116 kB]
Ign:2 testing/updates InRelease 
Err:3 testing/updates Release   
  404  Not Found [IP: 80]
E: Repository ' testing InRelease' changed its 'Codename' value from 'buster' to 'bullseye'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N]

Then I got to thinking, do I want to accept these changes?  What might my options be?
I should inform that these laptops will be used by younger students who are not Linux savvy, so I don't want the students to have to worry about too many Linux problems, like new packages breaking the system or too many changes needed.

At the moment, the Debian repositories read:

Quotedeb testing main contrib non-free
deb-src testing main contrib non-free
deb testing/updates main contrib non-free
deb-src testing/updates main contrib non-free
# deb testing main non-free

And sparky-testing.list:

Quote### sparky core repository is used by all sparky editions
deb core main
deb-src core main

### sparky testing repository
deb testing main
deb-src testing main

And sparky-unstable.list:

Quote### sparky unstable repository
deb unstable main
deb-src unstable main

There are others.  So I see my choices as:
1.  Going from testing to stable.  I could eliminate sparky-unstable.list and change everything from testing to stable.  This would be an effort to make for fewer surprises for users.
2.  Going from testing to buster.  This might not be a big change since I think testing might have been buster when this system was installed.
3.  Leaving things as they are, choosing yes to proceed with the upgrade and hope that the good people at Sparky will keep out things that will break the system.  This might appeal if choices 1 or 2 end up making things weird anyway.
4.  Try installing a new system.  This may be time consuming as it will require lots of various tweaking afterwards.

Any ideas on what the best choice might be?  Or something different from above?


Best choice is dependent on skills (esp. skill set of person receiving the laptop), up time requirements and security requirements.

For myself I would probably track testing.  BUT.  A. Corona and possible slowing of development and delays.  B.  python2-rm and other ongoing transitions.  Example of A is   
No movement on that bug since March 22 in Sid.

B.  - more than a few programs will disappear in testing via the python2-rm.  Upstream had 10 years to transition to python3 in some cases.   

Being a "mission critical" computer -  having either "buster" or "stable" in your sources.list would be quite rational.   

peace out.  Stay the ... home.  Moi, off to be on first line of defense for vulnerable people. 

Search forum for "More info easier via inxi"    If requested -  no inxi, no help for you by  me.


Thank you paxmark1 for your reply.  Your insights were helpful.  I realize there's no black or white answer, but I went ahead and changed all references of sid or testing to stable and "upgraded".  Even though it sounds like a downgrade, well over a hundred packages were upgraded and the system is working well, except for one small glitch I'll post elsewhere so as to keep on topic. 

View the most recent posts on the forum