Netrunner Home

[solved] Netrunner 19.01 Desktop Debian based


#21

Thank you. What’s about mixing testing and stable?


#22

You can either use the branch or the code names, but it’s not recommended to use both. It’s also not recommended to mix testing packages with a stable base, the packages are newer and are compiled against newer libs, etc., than whats available in stable (aka you can easily break your system). The current stable release is stretch which was released on June 17th, 2017, thus the package versions would typically be to old to be combined with testing. Keep in mind that testing (currently buster) also receives security updates, so this is not an actual issue. Personally, I would just track buster, this way you don’t need to worry about whether it’s state is testing or stable. However, as leszek pointed out, if you wish to stay on stable even past buster, then you can switch to using the stable branch name after buster is moved/merged into stable.


#23

Possible but not recommend.


#24

Thank you to all. It’s solved: I will let all as it is as Leszek recommended. James thank you to you for your clear tip too.


#25

I saw the topic was Netrunner 19.01 core, but I am using Netrunner 19.01 Desktop Debian. I hope your answers were not belonging to Netrunner 19.01 core? AJSlye: with tracking only buster, do you disable testing or let both active?


#26

Dude, seriously. Buster is testing, ATM.
I set all my repo’s to buster, none of them are set strictly to testing.
Once Buster is moved to stable, then i’m on stable, no need to change anything.
Testing will then be whatever the next code name is.

Now, on my media server (stretch based), I have it set to stable instead of stretch so that when buster is moved into stable it will update to it automatically. This media server can benefit from the update to buster (media codecs, etc.). My web server on the other hand, is staying on stretch where it will continue to get security updates until 2022. However, my backup server which I never touch besides uploading and downloading files to it, is still on jessie until right before it hits EOL in 2020, then I’ll move it to stretch.
https://wiki.debian.org/LTS


#27

AJSlye: good answer. We are talking about Netrunner 19.01 Desktop Debian, it’s a testing snapshot. If I always track buster(now testing)/ later on stable then I will get all updates from the stable version and never again from testing and I will loose the netrunner base, isn’t it? If I add later on testing again, then I will get a dangerous mix between branches, isn’t it?


#28

The netrunner packages are on their own servers are they not?
The base would make little difference to these, afaik.
Now backports, etc., might have issues unless set to match the main debian repos (stable, testing, buster, etc.)


#29

I am a newbie (Debian etc.), what does it mean?


#30

Leave your system at buster currently and don’t worry too much :stuck_out_tongue:


#31

Thank you for your great message!


#32

I jump in this conversation to continue clarification as I am interested to point out Buster and stay with a stable Debian basis.

I can already point my repository to Buster so then I am today almost on stable and I will definitively be when Buster is released as the new stable Debian.

What then will happen with the Netrunner repository that are in my config (deb.netrunner.com). Should I keep them or deactivate them ?
Will I receive update of KDE (plasma and app) if I stay on Debian Buster ?


#33

You can keep them. Nothing much will happen there by default.

No major updates will come to Debian Buster I think when it comes to Plasma.
In all honesty with Plasma 5.14 they aren’t really needed. The desktop runs pretty stable and good.


#34

Thanks @leszek for your answer !

So I understand that Plasma 5.14 won’t be upgraded.
But will Netrunner Core receive regular updates, bugfix, and changes of the 5.14 branch (I see we are now on the 5.14.90) ?
Or do you mean that Plasma and KDE apps will be frozen, without even bugfixes ?


#35

There will be only bugfixes coming from Debian. We don’t build our own Plasma versions.


#36

Thanks for these informations !