Debian sid FAQ

A lot of people get frustrated because they perceive the Debian stable
release to be "too old", sometimes because they bought some
crazy new hardware gadget which needs a very recent kernel to support,
and sometimes just because they've been brainwashed to think that if
they aren't running the "newest version" of package foo, then
they're somehow inadequate. So they start running unstable (sid).

And then they come into #debian when it breaks.

And then they don't understand why we're so mean to them.

The purpose of this document is to describe what you did wrong, or
why you were flamed; and what you should have done differently.

This FAQ is most especially aimed at Slashdot readers. If you
aren't sure whether this includes you... it includes you.

Sid users who want to know whether there are any traps awaiting them if
they upgrade are advised to check the /topic of the #debian
channel, and the Status
of Unstable page.

Finally, please note that this document is not intended to be a general
Debian FAQ, nor even a #debian channel FAQ. For definitive documentation
about Debian, see debian.org. For
the #debian (Freenode) channel FAQ, check
The Debian wiki.

Sid is the unstable branch of Debian. All of Debian's branches and releases
have "code names" which are from the movie Toy Story. For
example, Debian 3.0 is code-named "woody". Sid was the kid who
broke all the toys. Some people think sid is an acronym for "Still In
Development". This is cute, but inaccurate.

What is unstable?

Unstable is where packages go after they've been uploaded by the maintainer,
and cleared for release by the FTP master. If you use an unstable package,
the only thing you can say with any certainty is that it compiled on the
developer's system. It may contain
horrible bugs.

When packages have met certain criteria, they are automatically moved
from unstable to the current "testing" branch. For more information
about testing, see
the
testing announcement.

The canonical answer is: You don't. You can only upgrade to it from
stable or testing. You do that by editing /etc/apt/sources.list
and changing your sources from stable to unstable.

There are some unofficial "sid ISO images" out there.
They are dangerous, unofficial and obsolete (by definition!). Stay away
from them.

It may also be possible to install sid packages instead of testing packages
if you're using a net install from the testing branch. This is not supported,
but if you want to try it, you're free to do so. It's your machine, after all.
Just don't cry if it breaks.

Does sid have package foo?

Don't ask us -- you have the same resources available to you that we have!
Here are some of them:

On your local Debian system, apt-cache search and
apt-cache show will tell you what packages are available
from your sources.

In the #debian channel, the bots (apt or dpkg, whoever's present) can
be asked to search for package information. Type /msg apt info libc6
sid to see the version information for the libc6 package in sid,
for example.

If you ask the #debian channel whether sid has something (KDE version 3.2b
or GNOME 2.5 or frobbitz version 42), we won't know! We would have to check
for you, and then tell you. This is a sign of laziness on your part.
You should check for yourself.

Is package foo broken?

Once again, how would you expect us to know? If it doesn't work for you,
then there's a good chance it's broken -- but your problem may be common
among users of package foo, or it may be unique to your system. That's why
Debian has a Bug Tracking System.
(You'll also see this called the BTS.) Check there before you ask
for help with a package in sid. If you don't see your bug there, but you
think it's a real problem in the package, then file a bug report yourself.
(You can do this with the reportbug package.)

If you don't see your problem listed in the BTS, but you aren't sure
whether it's a real bug or just something you did wrong, then by all means
ask for help. Be specific when you ask for help -- say what version
of Debian you're using, what version of package foo, what you're doing (or
trying to do), and what the error message says.

The Status of Unstable
page may also contain information relevant to your situation. You should
definitely check there before reporting problems.

Failure to do your homework before asking for help with a package in sid
demonstrates your laziness. We won't take you seriously until you've shown
that you're taking Debian seriously.

How do I know what version of package foo I'm using?

If you don't know how to use the Debian package management tools, you
should not be using sid! Really. That's probably part of the reason
we flamed you.

sgeigerbot has a package
management guide that may be helpful for those of you who were smart
enough not to use sid yet. For more information, see the man pages
(man dpkg, man apt-get,
man apt-cache, etc.)

When will package foo version bar be in sid?

When it's ready.

But I need package foo version bar right now!

Then go ahead and package it yourself. See the information in the
Developers' Corner for details.

Can I use sid packages on stable?

No. Don't even bother trying. If you do it anyway, you get to keep
all the pieces, and we get to laugh at you.

Can I use sid packages on testing?

Only if the dependencies are satisfied. In general, sid and testing are
usually close to each other, except for when RC (release critical) bugs in
some major package like libc or perl cause a slew of things to be held up.
So your odds of getting the binary package to work in testing are pretty
good... but you still need to check it out yourself.

If the library dependencies aren't satisfied, then you'll need to backport
it.

How do I backport a sid package to testing or stable?

Install the Debian source (and the development tools, especially
debhelper), and then build the package. Step by step:

If you think you can handle a broken Debian system, sure. Do you know
what to do if libpam0g breaks, preventing all logins? Do you know
what to do if grep breaks, causing the boot process to hang forever?
These things have happened. They will happen again.

If you'd like to avoid the brown-paper-bag bugs like these, then use
testing instead.

Does sid have security updates?

Not in the same sense that stable does. If the maintainer of a package
fixes a security bug and uploads the package, it'll go into sid by the normal
means. If the maintainer doesn't do that, then it won't. The security team
only covers stable (and possibly testing... there's a pending issue for that
case).

Never. Sid will always be the unstable branch. When testing is
released, then a new testing will be created (with a new codename), and
packages will continue to trickle down from sid into testing just like they do
now.