Should I choose Testing [EE] ?

Talking about SolydXK, another distribution or totally off-topic but within the Rules ? It's the right place!
User avatar
petsam
Posts: 18
Joined: 16 Sep 2014 12:14
Location: Thessaloniki/Greece

Should I choose Testing [EE] ?

Postby petsam » 06 Mar 2018 00:24

Hi all!
I 've been a SolydK user from long time, I then switched to Manjaro for the last two years and I 've been in the root to rebase to Debian.
Obvious for me this familiar friendly distro.
Messing with the harcore(?) linuxers, I dived a lot on troubleshooting reading TFM.
Interesting but exhausting. I was tuned to the Testing branch in Manjaro, which is more stable than Arch Stable.
Comparing the package versions of Manjaro and Debian I saw that Mj stable are almost aligned to Deb Sid.
I am just not fully acustommed to the debian troubleshooting. Don't know where are the things I need to check when investigating an issue or try to alter some setting. I know it needs some time.
I would like some opinion on that or better an advice.
I am sure I have some experience to give back to the forum in my free time.
I am now on SolydX Stable and I was thinking on having an Arch or/and Manjaro on VB (for reference on troubleshooting and for newer versions of apps). I scanned Debian wiki for help and I find it not so up to date with today (just an impression after the experience of Arcwiki).
My main personnal projects are on Drupal (so LAMP) and maybe(?) some simple scripts.
How would you suggest for Testing and maybe some info to read on current Debian setup/configuration?

Thanks, anyway.

kurotsugi
Posts: 2103
Joined: 09 Jan 2014 00:17

Re: Should I choose Testing [EE] ?

Postby kurotsugi » 06 Mar 2018 01:43

since you're already accustomed with arch/manjaro I think there won't be any problem using the enthusiast version. the routine is roughly same - keep your system updated and make regular backup. almost all debian packages are pre-configured so you might not need config anything except for specific reason. compared to manjaro, debian testing is more stable but have slightly older softwares. it would be depends on your need. if you want a stable rolling distro, debian testing it is. if you want bleeding edge rolling distro, debian sid is better.

I think the main thing you should keep on mind is that on enthusiast we use "apt-get dist-upgrade" instead of "apt-get upgrade". once you know how to do regular update you can keep rolling :3

User avatar
ilu
Posts: 2045
Joined: 09 Oct 2013 12:45

Re: Should I choose Testing [EE] ?

Postby ilu » 06 Mar 2018 13:49

Regarding documentation: Nothing on the internet comes close to ArchWiki. If docu quality was the deciding factor for choosing a distro, everybody would have to use Arch. :mrgreen: Whenever I encounter a problem I look up ArchWiki. Most of it's info applies to Linux in general.
The debian docs are often old. But if you need to troubleshoot something go to f.e.https://packages.debian.org/stretch/apache2 and have a look at the ressource links on the right side.

User avatar
petsam
Posts: 18
Joined: 16 Sep 2014 12:14
Location: Thessaloniki/Greece

Re: Should I choose Testing [EE] ?

Postby petsam » 06 Mar 2018 14:28

ilu wrote:But if you need to troubleshoot something go to f.e.https://packages.debian.org/stretch/apache2 and have a look at the ressource links on the right side.
That kind of tip I was looking for!! :clap: Thanks and I will wait for the rest of them :D
kurotsugi wrote:I think the main thing you should keep on mind is that on enthusiast we use "apt-get dist-upgrade" instead of "apt-get upgrade". once you know how to do regular update you can keep rolling :3
Thanks for the tip. Maybe there is a topic or link to help me understand better the policy that is used in [EE] for updates?
Also a question. Trying to familiarize with the Debian branches I 've read the Debian wiki and saw that there is a very nice mechanism with apt pinning that, if used wisely could give you the good things from all branches. I remember an old friend of mine had stated that he was using this kind of combination that was complicated and not easy for normal users. Do any of you use this kind of method and if you can share an insight? Not that I would straight ahead go for it but I would like to prepare myself. :P

I appreciate the info. Please keep them coming!

kurotsugi
Posts: 2103
Joined: 09 Jan 2014 00:17

Re: Should I choose Testing [EE] ?

Postby kurotsugi » 06 Mar 2018 17:54

the enthusiast is based on testing so it follow the debian package migration mechanism on debian. but first, you might want to know how debian works. first of all, debian consist of four branch :
- stable : the official released version
- testing : a branch where new debian is prepared
- sid/unstable : also a branch where new debian is prepared, but it's where the package maintainer upload his packages.
- experimental : only for testing. strictly used only by developers. highly unstable.

the stable is a fixed release (i.e: it only receive security updates) while the testing and sid are rolling. don't be confused with the name. testing isn't where the debians do the "test". testing and unstable is a branch made to prepare the next debian stable release. despite of the name, testing and unstable are actually quite stable for daily use. the actual "testing" branch is experimental. also, testing and unstable is more or less actually one single branch where new debian release is prepared.

the differentiation was made to ensure that the next stable release would be met all the criteria to be released (stable, secure, no RC bugs, etc). aside from the differentiation, debian also made a package migration mechanism. the process is more or less like this :
1. the new package uploaded to sid.
2. it stay on sid for several days.
3a. if there's no new bug and it met the migration criteria, it will migrated to testing.
3b. if it doesn't met the migration criteria, it will stay on sid until new package got uploaded.

these mechanism will ensure that the testing branch should be stable enough for daily use. as end user, we simply choose which branch to be used (testing or sid). the main differences are:
1. sid has slightly newer packages
2. breakage happened more often on sid.

though, since sid and testing are actually one branch, if you're using sid and not update your system (let say, for 2 weeks), at the end of the period your system would be identical to testing. this is also why you could use sid and testing at the same time and got all the good thing from both branch. the key would be a good repo management.

the repo management is done by apt-pinning. but before that, you need to keep on mind that apt (the package management tool in debian) is mainly designed for doing upgrade. it won't, and it can't downgrade package without some tricks (even with those tricks there's no guarantee it will succeed). apt-pinning is act as a guide for apt to choose how the upgrade is done.

DISCLAIMER - IT WILL BE A LONG POST
ignore this point below if you feel the current enthuiast is enough for you. apt-pinning is simple but dangerous thing.

apt-pinning works on simple logics.
1. it will check the installed package and compare with the repo
2. if the repo contain newer package, it will update it.
3. if there are multiple repo, it will see the repo priority.
4. if multiple repo got same priority, it will see which one got newest package.

a basic multiple repo would be like this. this is an example of /etc/apt/sources.list content for the enthusiast.

Code: Select all

#main repo
deb http://repository.solydxk.com/ solydxk main upstream import
deb http://deb.debian.org/debian testing main contrib non-free
deb http://deb.debian.org/debian sid main contrib non-free


with this repo entry, without apt-pinning, upon doing a dist-upgrade my system will be upgraded to sid. there would be several scenario of using multiple repo.

here's an example of an apt-pinning (the content of /etc/apt/preferences)

Code: Select all

Package: *
Pin: origin packages.solydxk.com
Pin-Priority: 400

Package: *
Pin: release a=unstable
Pin-Priority: 50

Package: libreoffice*
Pin: release a=sid
Pin-Priority: 600
Package: *
Pin: release a=unstable
Pin-Priority: 50

the first part define where it applied. (*) means it applied for all package. you can use a package name for a more detailed setting. the second part is the ID for the pin of the repo. if your run apt-cache policy, you'll see that each repo has it's own identity. you can use either release pin or the origin pin. the example above is using release pin since it's more generic and can be applied for multiple repo entry. you can use there pin ID for your advantages.

Code: Select all

apt-cache policy
Package files:
 100 /var/lib/dpkg/status
     release a=now
 500 http://ppa.launchpad.net/numix/ppa/ubuntu xenial/main i386 Packages
     release v=16.04,o=LP-PPA-numix,a=xenial,n=xenial,l=PPA for the Numix Project Ltd.,c=main,b=i386
     origin ppa.launchpad.net
 500 http://ppa.launchpad.net/numix/ppa/ubuntu xenial/main amd64 Packages
     release v=16.04,o=LP-PPA-numix,a=xenial,n=xenial,l=PPA for the Numix Project Ltd.,c=main,b=amd64
     origin ppa.launchpad.net
 500 http://liquorix.net/debian sid/main i386 Packages
     release o=liquorix,a=unstable,n=sid,l=kernel,c=main,b=i386
     origin liquorix.net
 500 http://liquorix.net/debian sid/main amd64 Packages
     release o=liquorix,a=unstable,n=sid,l=kernel,c=main,b=amd64
     origin liquorix.net
 500 http://deb.debian.org/debian testing/non-free i386 Packages
     release o=Debian,a=testing,n=buster,l=Debian,c=non-free,b=i386
     origin deb.debian.org
 500 http://deb.debian.org/debian testing/non-free amd64 Packages
     release o=Debian,a=testing,n=buster,l=Debian,c=non-free,b=amd64
     origin deb.debian.org
 500 http://deb.debian.org/debian testing/contrib i386 Packages
     release o=Debian,a=testing,n=buster,l=Debian,c=contrib,b=i386
     origin deb.debian.org
 500 http://deb.debian.org/debian testing/contrib amd64 Packages
     release o=Debian,a=testing,n=buster,l=Debian,c=contrib,b=amd64
     origin deb.debian.org
 500 http://deb.debian.org/debian testing/main i386 Packages
     release o=Debian,a=testing,n=buster,l=Debian,c=main,b=i386
     origin deb.debian.org
 500 http://deb.debian.org/debian testing/main amd64 Packages
     release o=Debian,a=testing,n=buster,l=Debian,c=main,b=amd64
     origin deb.debian.org
the number on the leftmost part (as in "500 http://deb.debian.org/debian testing/main amd64 Packages"). means the the repo priority point. you can define it on the third part of apt-pinning.

things to remember:
1. installed package got 100 point
2. all repo except experimental by default got 500 point
3. experimental got -1 point
4. the point value is 0 to 1000
5. -1 means it will never used unless the user specify it
6. 1001 means that this repo got highest priority

all the apt-pinning behaviour is actually based on these point. for an example, apt will always looking for newest package because the repo got 500 while the installed package is 100. if you set a repo point lower than 100 it means that apt will never take a look into that repo.

let's go back to our example

Code: Select all

#this entry means that the repo from debian got higher priority than solydxk repo. it is usefull if solydxk repo and debian repo has several same packages.
Package: *
Pin: origin packages.solydxk.com
Pin-Priority: 400

#this entry means that unstable is locked and will be ignored during dist-upgrade. it is usefull as a safety lock to prevent breakage
Package: *
Pin: release a=unstable
Pin-Priority: 50

#this is an exception of the entry above. libreoffice would be always taken from sid. this is an example of apt-pinning manipulation for a specific advantage.
Package: libreoffice*
Pin: release a=sid
Pin-Priority: 600
apt-pinning works on simple logic so there's no certain way to achieve something. here's an example:
CASE 1: I want to use testing but I want package A to be taken from sid.

the first thing you need to do is lowering the point of sid. that way, you'll always stay on testing. this one should enough

Code: Select all

Package: *
Pin: release a=unstable
Pin-Priority: 150
no need to define testing since the default value is 500. either way this one should works too

Code: Select all

Package: *
Pin: release a=testing
Pin-Priority: 650
after that, you need to find out how to get package A from sid.

method 1: use "apt-get install -t <branch name> <package name>" pattern.
initially it will install that package from sid. after that, as installed package, the value is 100. it won't look into testing since testing got lower version number (older. remember that apt only do upgrades?). the upgrade would be taken from sid because it has higher value.

method 2: use this pinning then do a dist-upgrade

Code: Select all

Package: libreoffice*
Pin: release a=sid
Pin-Priority: 700
good...apt-pinning is usefull. I should use it right away, right? unfortunately, NO

here's the problem : apt-pinning is simple but powerfull. it control the whole apt behaviour so using bad apt-pinning means it could broke your system. here's an example. as I mentioned before, apt won't and can't downgrade packages. well...with a trick, it can. if you're on sid and want to go back to testing, this repo entry and the apt-pinning could do that.

repo entry

Code: Select all

deb http://deb.debian.org/debian testing main contrib non-free
deb http://deb.debian.org/debian sid main contrib non-free
apt-pinning

Code: Select all

Package: *
Pin: release a=testing
Pin-Priority: 1001


however, if you have this entry,

Code: Select all

deb http://deb.debian.org/debian testing main contrib non-free
deb http://deb.debian.org/debian stable main contrib non-free
apt-pinning

Code: Select all

Package: *
Pin: release a=stable
Pin-Priority: 1001
stable and testing is vastly different. this entry will forcefully downgrade your whole system to stable. it's a recipe for disaster.

well...no one would use that obvious example, right? yes...but in reality there are lot of less obvious case which actually as dangerous as that one. here's one. this is more or less my current repo list.

Code: Select all

deb http://packages.solydxk.com/testing/ solydxk main upstream import kdenext
deb http://debian.solydxk.com/production testing main contrib non-free
deb http://debian.solydxk.com/production/multimedia testing main non-free
deb http://debian.solydxk.com/security testing/updates main contrib non-free
deb http://community.solydxk.com/testing/ solydxk main

#liquorix
deb http://liquorix.net/debian sid past main

#tlp n dropbox
deb http://ppa.launchpad.net/linrunner/tlp/ubuntu lucid main
deb http://ppa.launchpad.net/numix/ppa/ubuntu trusty main 
deb http://ppa.launchpad.net/rebuntu16/other-stuff/ubuntu saucy main

#testing
deb http://ftp.nl.debian.org/debian testing main contrib non-free
deb http://packages.linuxmint.com/ debian main upstream import
deb http://security.debian.org/ testing/updates main contrib non-free
deb http://www.deb-multimedia.org testing main non-free

#unstable
deb http://ftp.nl.debian.org/debian unstable main contrib non-free
deb http://www.deb-multimedia.org unstable main non-free
yep. you saw it right. there are two debian branch (testing and sid) combined with solydxk repo and external 3rd party repo. there are also ubuntu's PPA's there. it's all possible with a good apt-pinning. a single wrong apt-pinning entry could easily destroy the whole system. actually...it already happened. it was a repo entry from my old system. I forgot to set the safety lock mechanism on the apt-pinning and the system is broken :lol:

kurotsugi
Posts: 2103
Joined: 09 Jan 2014 00:17

Re: Should I choose Testing [EE] ?

Postby kurotsugi » 06 Mar 2018 18:08

btw, the enthusiast usually follow this thread viewtopic.php?f=78&t=6917

User avatar
ilu
Posts: 2045
Joined: 09 Oct 2013 12:45

Re: Should I choose Testing [EE] ?

Postby ilu » 07 Mar 2018 15:59

I always wanted to compile a tutorial named "kurotsugi on apt pinning". Now this post is a definitive release candidate :ugeek:

I just have to figure out how to copy the post instead of moving it ...
Edit: Easy-peasy and done!

User avatar
petsam
Posts: 18
Joined: 16 Sep 2014 12:14
Location: Thessaloniki/Greece

Re: Should I choose Testing [EE] ?

Postby petsam » 08 Mar 2018 01:16

ilu wrote:I always wanted to compile a tutorial named "kurotsugi on apt pinning". Now this post is a definitive release candidate :ugeek:

I just have to figure out how to copy the post instead of moving it ...
Edit: Easy-peasy and done!
I am happy I helped on motivation!
Excellent info, I feel honoured for the disclosure. I always thought these are well kept mystical secrets between the long-beard gurus. :mrgreen:

User avatar
tardy
Posts: 43
Joined: 31 Mar 2014 17:16

Re: Should I choose Testing [EE] ?

Postby tardy » 08 May 2018 21:10

Good gosh, kurotsugi, that is an absolutely amazing tutorial/explanation. You've gone above and beyond with this one :clap: .

We should take up a collection and hire you to write the SolydWiki.

Hell, PM me a PayPal address and I'll buy you a few beers. Good beers.


Return to “Open Chat / General Discussion”

Who is online

Users browsing this forum: No registered users and 3 guests