testing sources list

[squirrelsoup]

to fully support my newer hardware i wanted to go Debian testing however i would like to know if this is good sources.list:

Code: Select all

deb http://httpredir.debian.org/debian testing main
deb-src http://httpredir.debian.org/debian testing main

deb http://httpredir.debian.org/debian testing-updates main
deb-src http://httpredir.debian.org/debian testing-updates main

# deb http://security.debian.org/ jessie/updates main
# deb-src http://security.debian.org/ jessie/updates main

deb http://security.debian.org testing/updates main

# jessie-backports
deb http://httpredir.debian.org/debian jessie-backports main contrib non-free

i am using back-ports for the nvidia proprietary driver

[dasein]

Conventional wisdom suggests that if you have to ask, you are simply not ready to run Testing.

[bw123]

to fully support my newer hardware i wanted to go Debian testing

I don't think you will get any newer hardware support on testing than you can get from the newer kernel in jessie-backports?

I'm not against you using testing, if you understand how to deal with it and file the bug reports that are really needed right now. If you're just a user like me, then I'd recommend stable plus backports.

If you want to stay on testing and help, then I think as a 'testing' system you should be willing to install the debug versions of programs, you should understand how to use patch files, possible even patch the kernel. It's tricky, but you should be able to somehow tell the difference between a configuration problem and a real 'bug' in a package. If the maintainer asks you to try a patch, or provide debug info, you should be able to do that.

Also, I searched your previous posts and saw one related to 'security' and I am pretty sure that testing receives no security updates, while stable does receive them regularly. Here's the link I use.

deb http://security.debian.org/ jessie/updates main

[pylkko]

Actually, it is worse than that. Because testing packages are often older than backports. For example, if the argument is supposedly based on needing support for newer hardware, then probably we can assume that a newer kernel would help. However, the kernel in testing is now 4.9.6, while the kernel in backports is at 4.9.13. This is not the only package, of course, almost every single new package goes to backports before it goes to testing.

[emariz]

Actually, it is worse than that. Because testing packages are often older than backports. For example, if the argument is supposedly based on needing support for newer hardware, then probably we can assume that a newer kernel would help. However, the kernel in testing is now 4.9.6, while the kernel in backports is at 4.9.13. This is not the only package, of course, almost every single new package goes to backports before it goes to testing.

This is not true. Backports are, factually and by policy, taken from Testing. Only security updates may be taken directly from Unstable, which is also true for Stable.

If one looks at the differences between the versions in Jessie-Backports and Stretch (1): Today, 850 out of the 1803 available backports are at the same version in Jessie-Backports and Stretch, 633 are outdated in J-B, 252 are older in J-B, and only 7 packages in J-B are at a newer version than in Stretch. Among these seven packages is new kernel (the others are either blocked by the current freeze or have been removed from Stretch.)

And when one checks the kernel changelog (2), one notices that version 4.9.13-1~bpo8+1 was uploaded to Jessie-Backports eight hours after its availability in Unstable. One has to imagine that such a fast upload was allowed only because of a security fix, even though there was no security announcement related to the kernel in the corresponding Backports Security Announcements mailing list (3).

In any case, if one picks any other backport, there is an extremely high chance that it was uploaded to Backports about one week after it had already been uploaded to Testing.


1. https://backports.debian.org/jessie-backports/overview/
2. http://metadata.ftp-master.debian.org/c ... _changelog
3. https://backports.debian.org/Mailinglists/

[emariz]

to fully support my newer hardware i wanted to go Debian testing

As already mentioned, if hardware compatibility is your main concern, Stable plus Backports should suffice.

Some questions, though:
1. Why do you need the source (src) entries?
2. Are you only going to use packages available in the Main component of the archive?
3. What does the testing-updates archive include?

[pylkko]

Actually, it is worse than that. Because testing packages are often older than backports.

This is not true.

Except that it is vert true (even though what you say is technically correct). In practice this is something that happens. Yes, these packages are often security. For example the Firefox esr point releases always reach backports a week before they go to testing. The same appears to be the case with Libre office. And when the 4.10 kernel comes to Debian, it will have to wait for 10 days minimum until it reaches testing (unless hurried).

At the end of the day, testing does not even suit the ill purpose of having the latest stuff very well. Choosing another distro one could get all these new packages the day they are released.

[aplistir]

Here is my sources.list:

Code: Select all

deb http://ftp.fi.debian.org/debian/ stretch main non-free contrib
deb http://security.debian.org/ stretch/updates main contrib non-free

# stretch-updates, previously known as 'volatile'
deb http://ftp.fi.debian.org/debian/ stretch-updates main contrib non-free

#google chrome
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

Few points:
1. Testing is frozen and it will soon become the next stable. No new big changes will be made anymore, so testing is much safer to use than eg. a year ago. There are still some bugs, but also some annoying bugs Jessie still has, have been corrected.

2. Use "stretch" instead of "testing". Or your system will become very unstable, when stretch becomes stable and new testing is created.

3. I don't have the src entries in sources.list unless i need them, which is rarely.

4. I have enabled contrib and non-free, since there are lots of important packages.

5. I have chrome, and prefer tho have chrome repository in the sources.list instead of sources.list.d -folder. In my opinion it is clearer to have all repositories in a single file. This is a matter of opinion.

6. Stretch (testing) updates probably wont have much in them yet, but after stretch becomes stable, I will already have the line, so I wont need to add it later.