It should be interesting then... I hope to learn a lot. By broken, do you mean that there will be wrong dependencies? wrong versions of libraries?

It will be fun.

Once Etch gets released all the packages that have been held in experimental will flood into Sid. For a couple of months after Etch is released Sid will once again earn its name as "Unstable".

Just make sure you keep an eye on what apt-listbugs and apt-listchanges tells you and you will be just fine.

If something says it has "grave" bugs especially ones that have to do with booting or essential services do not upgrade them, simply put them on hold.

When Sarge released I had around 400 updates that I waited 2 or 3 months to finally update.

so how does that work when there are security issues with a package or service? will the security repos work without problems? Good thing I installed Sid before Etch was released. (even though it is on a spare box)

Sid's relationship with the security patches is a little complicated. Here is a typical situation that should illustrate what happens.

Say you install a program, for this example named php-junk-2.1.6 under sid. For a full illustration, lets say testing uses php-junk-2.1.0, and stable is on php-junk-1.8.0.

Now say there is a flaw found in the generic php-junk package. What will shake down is something like this - The php-junk developers will release a new version, probably php-junk-2.1.7, which is likely to be 2.1.6 with the flaw fixed. Now sid being sid (the best imho), whoever is maintaining that particular package for Debian will grab the source tarball, build it on their own (yes, some folks in the real world do still compile from source) and will then publish a debian package (.deb) file on the repositories. It might sit in experimental a few days, or it might go direct into the sid package list, depending on several factors. There will be no "security" release for sid, because the new version with the problem fixed is now available. There might be a lag of a few days from when the flaw is written up until a deb package is made, and again until it becomes available in the mainline repositories. In short, Sid doesn't get security fixes because it keeps the version up to the latest and greatest as much as possible.

Testing gets some security releases. There are many variables involved with how/why this happens. The next version in testing could come quickly from the security team, it could come from the package maintainer, it could come from somebody else. Say the flaw is a big deal, like a serious problem that allows remote access. If the Debian security team gets on it, what they might do is release a security package. Now remember, Sid had the problem fixed by going from php-junk-2.1.6 to 2.1.7. Testing started with php-junk-2.1.0. They will probably create a subversion number over the fix, because 2.1.1 would exist "in the real world", so they would likely release something like php-junk-2.1.0.1 for Debian testing. It is still effectively 2.1.0, but it fixes the security hole. What I don't know for certain is how the hierarchy works with testing or stable. For example, Testing is usually "slightly stale" Sid, like Sid from 6 months ago or so. Now this being a serious security hole, can the package maintainer just upload 2.1.0.1 into testing, does it have to be approved by security, does it need to be tested in Sid a bit? I have frequently read the security team is seriously understaffed, so I'm sure they appreciate any help they can get, I just don't know the "rules" about how things are sorted out.

Stable is yet again a different beast. In the first place, they have php-junk-1.8.0 in my example. Does the flaw found even effect 1.8.0? If the code with the flaw wasn't introduced until php-junk 2.0.0, then stable has nothing to worry about, their version isn't at risk. That is one of the many benefits of running stable for servers. Yes you won't have the latest and greatest by any means, but what you have is old, and "stable". The bumps in the road are smoothed out by Sid and Testing, and Stable chills with a version older than the code with problems. The whole idea with Stable is that they won't usually introduce "new functionality" releases into Stable, they will keep things running on the same basic version forever, and just do updates for security. So if the flaw does effect 1.8.0, then the process goes ahead. If the security team does it, then it will probably be another subversion, php-junk-1.8.0 will be upgraded to php-junk-1.8.0.1, again it is still 1.8.0 with no new features, just the hole patched. With stable in particular I think the package has to go through the security team to get released, but the internals of the Debian team are beyond me.

Long story short, everybody gets patched up or upgraded past the problem version, just in different ways. Sid doesn't get security patches, it just gets the new version of the package, with the security issue fixed, and then the problems with the new version get minimized and passed on to Testing, who repeat that process more rigorously, and then it will eventually, (usually years later), that package will make Stable.

Sorry this got longwinded.

Peace,
JimBass

JimBass explained it very well. If you are on the Security mailing list you will notice 99% of the time the version in Sid is no longer vulnerable, while you have to wait for the update in testing and stable.

From a security view point running Sid is actually safer than stable or testing.

Actually, if it's a security problem of any note, it moves thru the system fairly quickly. Both Testing and Stable have security teams that are concerned with getting problems in their area addressed as quickly as possible.

Yes, the security patch will get through quickly, I meant it would be years before my php-junk-2.1.7 would make stable. Sorry if I wasn't clear about that.

Peace,
JimBass

Thanks for the detailed description JimBass, was a good read.

My pleasure. I'll take up a career as a novelist once my working days are behind me

Peace,
JimBass

Thanks for all the great info. My system is running perfectly, for now.

apt-listbugs is a great tool, and I never knew about it. It'll save me some time. Thanks!

I have been running Sid for about two weeks. Installed apt-listbugs after finding out about it in this thread. apt-listbugs gives this error after I run apt-get upgrade:

Fetched 41.5MB in 4m8s (167kB/s)
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... 0% Fail
Error retrieving bug reports from the server with the following error message:
W: unsupported proxy `false'
It could be because your network is down, or because of broken proxy servers, or the BTS server itself is down. Check network configuration and try again
Retry downloading bug information?[Y/n]?

does apt-listbugs have a bug? My network is fine.
Thanks folks.

Edit to add question:
This is my repo for security updates. Will these work for Sid?
deb http://security.debian.org/ etch/updates main
deb-src http://security.debian.org/ etch/updates main

As previously stated Sid does not have a security repo, apps get patched and moved directly into Sid. apt-listbugs works just fine for me. Also if you are running Sid you are better off using apt-get dist-upgrade than just upgrade.

Start a new thread and post your sources.list

Yes, that happened with the previous stable aswell.
Besides that I hardly ever run into trouble on SID. Nothing that can't be fixed or is auto fixed after a couple of days. I do remember that SID forced me to learn quickly a lot of years ago. So it might just be that 'No trouble at all' is just me.

I have to think hard though what the last time was that SID made me angry. I guess it has to be before the brilliant module-assistant and some fglrx driver wouldn't work. But he, that's in the past

Thanks, craigevil. Removed security.debian.org from sources.list