Differences between revisions 69 and 70
Revision 69 as of 2009-07-09 07:10:51
Size: 21892
Comment:
Revision 70 as of 2009-07-09 07:24:51
Size: 22409
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
## Please wrap your lines to something close to 80 characters. For the endresult
## it doesn't matter, but it makes the diffs easier to read (if you subscribe to
## changes)
Line 17: Line 21:
This page is meant to collect frequently asked questions from the [[http://lists.debian.org/debian-user|debian-user]] mailing list. The contents are licenced under the terms of GPLv2 or, in the event a DFSG compatible licence is applied to [[http://wiki.debian.org|wiki.debian.org]] at large, then under that licence. Posting material to this page is an acceptance of this. This page is meant to collect frequently asked questions from the
[[http://lists.debian.org/debian-user|debian-user]] mailing list. The contents
are licenced under the terms of GPLv2 or, in the event a DFSG compatible
licence is applied to [[http://wiki.debian.org|wiki.debian.org]] at large, then
under that licence. Posting material to this page is an acceptance of this.
Line 22: Line 30:
Line 25: Line 34:
Of course, you are free to do this. Almost all debian lists (including debian-devel) are open for anyone to post and Debian encourages users to file bugs in the Debian Bug Tracking System (BTS). '''BUT''', please consider following points first:
 * Make '''100% sure''' your problem needs direct attention of developers. Remember, Debian is created by volunteers in their spare time. Distracting them with other problems will leave less time to do actual work, like solving known bugs, package new versions of software we are all waiting for, packaging software not yet present in Debian and improving or creating Debian specific software. Even if you know you have a really difficult problem, debian-user is read by some '''very''' knowledgeable people (including some Debian developers), and they might have a solution for your problem.
 *
Some problems are caused just by misconfiguration. Sometimes even the most experienced people can do stupid things. Having other people look over your problem may help.
 *
Make sure your problem is not known. That means you should search the archives of debian-user (or other relevant lists) and especially the BTS. Chances are somebody else has experienced the same (or similar) problem and workarounds may be known. Even if you searched thoroughly, you should post to debian-user first (stating what you already tried/researched).

If you considered all above points and still want to address debian-devel, then please make sure:
 * your problem is not specific to a package (you could file a bug instead)
 * it
hasn't been discussed yet (you did search the archives, right?)
 * you are
addressing the right list (ex. legal stuff should go to debian-legal, website specific to debian-www, ...)

In case you have doubts just post to debian-user, sometimes answers come within minutes.

Of course, you are free to do this. Almost all debian lists (including
debian-devel) are open for anyone to post and Debian encourages users to file
bugs in the Debian Bug Tracking System (BTS).  '''BUT''', please consider
following points first:

 * Make '''100% sure''' your problem needs direct attention of developers.
 *
Remember, Debian is created by volunteers in their spare time. Distracting
 *
them with other problems will leave less time to do actual work, like
 *
solving known bugs, package new versions of software we are all waiting for,
 *
packaging software not yet present in Debian and improving or creating
 *
Debian specific software. Even if you know you have a really difficult
 *
problem, debian-user is read by some '''very''' knowledgeable people
 *
(including some Debian developers), and they might have a solution for your
 *
problem.  Some problems are caused just by misconfiguration. Sometimes even
 *
the most experienced people can do stupid things. Having other people look
 *
over your problem may help.  Make sure your problem is not known. That means
 *
you should search the archives of debian-user (or other relevant lists) and
 *
especially the BTS. Chances are somebody else has experienced the same (or
 *
similar) problem and workarounds may be known. Even if you searched
 *
thoroughly, you should post to debian-user first (stating what you already
 *
tried/researched).

If you considered all above points and still want to address debian-devel, then
please make sure:

* your problem is not specific to a package (you could file a bug instead) it
 *
hasn't been discussed yet (you did search the archives, right?) you are
 *
addressing the right list (ex. legal stuff should go to debian-legal,
 *
website specific to debian-www, ...)

In case you have doubts just post to debian-user, sometimes answers come within
minutes.
Line 38: Line 69:
Line 41: Line 73:
This is something that you as a user and administrator of your system have to decide for yourself. If you just need a few newer packages try http://www.backports.org before considering an upgrade. If you have Debian on a desktop machine testing might be an option, but it's not really recommended for production machines. If you want all the newest software Debian can provide and don't mind/can handle breakage then you could try unstable. If you are in doubt '''always use stable'''. Each Debian distribution has its pros and cons. Here are some:
This is something that you as a user and administrator of your system have to
decide for yourself. If you just need a few newer packages try
http://www.backports.org before considering an upgrade. If you have Debian on a
desktop machine testing might be an option, but it's not really recommended for
production machines. If you want all the newest software Debian can provide and
don't mind/can handle breakage then you could try unstable. If you are in doubt
'''always use stable'''. Each Debian distribution has its pros and cons. Here
are some:
Line 46: Line 86:
 * released approx. every 1.5 years.
 * has security support and occasional
bug-fixes (via the security archive, proposed-updates archive and point releases).
 *
very stable, thoroughly tested, recommended for environments where frequent changes are not desired and high uptimes are required.
 * can
have oldish software and may lack support for very new hardware.

* released approx. every 1.5 years.  has security support and occasional
 *
bug-fixes (via the security archive, proposed-updates archive and point
 *
releases).  very stable, thoroughly tested, recommended for environments
 *
where frequent changes are not desired and high uptimes are required.  can
 *
have oldish software and may lack support for very new hardware.
Line 54: Line 96:
 * testing is slowly evolving to become the next Stable release, but until released it is still testing ground. As the release approaches (testing freeze) it becomes more and more like a newer stable release (with all pros and cons).
 *
packages have already received some testing in unstable.
 * security support.
 *
bug fixes have to go through unstable first (usually 10 days, but can take longer). Because of this any breakage might take at least 10 days to be fixed.
 *
requires some skill to maintain.

* testing is slowly evolving to become the next Stable release, but until
 *
released it is still testing ground. As the release approaches (testing
 *
freeze) it becomes more and more like a newer stable release (with all pros
 *
and cons).  packages have already received some testing in unstable.
 * security support.  bug fixes have to go through unstable first (usually 10
 *
days, but can take longer). Because of this any breakage might take at least
 *
10 days to be fixed.  requires some skill to maintain.
Line 63: Line 108:
 * contains packages uploaded by the developers for the next release, but will never be released. Instead, packages will usually migrate to testing if no release-critical bugs are found in 10 days (and there are no dependency problems).
 *
most of the times has quite recent software or even bleeding edge.
 *
no security support similar to stable or testing, but updated packages should also incorporate security fixes.
 *
changes can/do happen even daily.
 *
serious breakage can (and will!) occur; requires good skills to maintain, but good for learning if you don't mind the downtime.

* contains packages uploaded by the developers for the next release, but will
 *
never be released. Instead, packages will usually migrate to testing if no
 *
release-critical bugs are found in 10 days (and there are no dependency
 *
problems).  most of the times has quite recent software or even bleeding
 *
edge.  no security support similar to stable or testing, but updated
 *
packages should also incorporate security fixes.  changes can/do happen even
 *
daily.  serious breakage can (and will!) occur; requires good skills to
 *
maintain, but good for learning if you don't mind the downtime.
Line 72: Line 121:
This is not a regular distribution (you cannot run on experimental), but it is mentioned here for completeness.
 * a place for maintainers to upload packages which are not suitable for unstable, but still need a wider audience for testing.
 * no security support and some packages can stay here for long times without any updates.
 * usage is '''not''' recommended unless you '''really''' know what you are doing.

This is not a regular distribution (you cannot run on experimental), but it is
mentioned here for completeness.

* a place for maintainers to upload packages which are not suitable for
 *
unstable, but still need a wider audience for testing.  no security support
 * and some packages can stay here for long times without any updates.  usage
 * is '''not''' recommended unless you '''really''' know what you are doing.
Line 80: Line 133:
That depends on how many and what packages you are using, but it can be more dangerous than running pure unstable. Installing packages from different releases can cause complex problems which are less likely to occur with packages from a single release. One example is that existing packages may become uninstalled due to internal restructuring of central components within the testing or unstable branches.

Try [[http://www.backports.org|backports]] first. If you can't find what you need there you can also backport a package yourself.

That depends on how many and what packages you are using, but it can be more
dangerous than running pure unstable. Installing packages from different
releases can cause complex problems which are less likely to occur with
packages from a single release.
One example is that existing packages may
become uninstalled due to internal restructuring of central components within
the testing or unstable branches.

Try [[http://www.backports.org|backports]] first. If you can't find what you
need there you can also backport a package yourself.
Line 92: Line 152:
Packages in Ubuntu main are very highly polished, very well maintained
and Canonical/Ubuntu go the extra mile to make the experience easy for
the user. That comes at one or more of several costs:
Packages in Ubuntu main are very highly polished, very well maintained and
Canonical/Ubuntu go the extra mile to make the experience easy for the user.
That comes at one or more of several costs:
Line 98: Line 158:
Lack of choice - you get one mail client rather than a choice of
several "out of the box", for example. Choices are made for you - its an
issue of supportability. Debian offers you more flexibility at the price
of complexity or being willing to support your choices.
Lack of choice - you get one mail client rather than a choice of several "out
of the box", for example. Choices are made for you - its an issue of
supportability. Debian offers you more flexibility at the price of complexity
or being willing to support your choices.
Line 105: Line 165:
Lack of architectures: if you're not on Intel/AMD64 or, possibly,
ARM/Sparc/PPC (depending on release) - you can't run Ubuntu. Debian
running on 11 or so architectures does mean that
 a) the process is sometimes slow
 b) the code gets debugged
c) is made portable/fixes are contributed upstream.
Lack of architectures: if you're not on Intel/AMD64 or, possibly, ARM/Sparc/PPC
(depending on release) - you can't run Ubuntu. Debian running on 11 or so
architectures does mean that a) the process is sometimes slow b) the code gets
debugged c) is made portable/fixes are contributed upstream.
Line 114: Line 172:
Canonical has relatively few paid developers, a highly motivated
volunteeer
developer community, a much larger community advocacy and
marketing budget and a vast number of new users. This does
mean that their developers are massively outnumbered by their users and
priorities have to be set. Packages in universe/multiverse may therefore
receive less attention than those in main in
Ubuntu.
Canonical has relatively few paid developers, a highly motivated volunteeer
developer community, a much larger community advocacy and marketing budget and
a vast number of new users. This does mean that their developers are massively
outnumbered by their users and
priorities have to be set. Packages in
universe/multiverse may therefore receive less attention than those in main in
Ubuntu.
Line 122: Line 180:
maintainer who takes an interest :) It does mean that Debian does much of
the heavy lifting of packaging and initial support for out of the way
packages - it also means that, if I want support for R and CRAN, for example,
I'd go straight to Debian because the maintainer has a personal and
professional interest for seeing it work well as an integrated system.
maintainer who takes an interest :) It does mean that Debian does much of the
heavy lifting of packaging and initial support for out of the way packages - it
also means that, if I want support for R and CRAN, for example, I'd go straight
to Debian because the maintainer has a personal and professional interest for
seeing it work well as an integrated system.
Line 130: Line 188:
"We demand rigidly defined areas of doubt and uncertainty" - Canonical
has
those because it releases once every six months. This consistency
comes at a
price: users expect new whizzy features with each release and
the development cycle is very short indeed. Long term support releases
happen every 18 months and are supported for three years on the
desktop/five years on the server. That's hard. It's _very_ hard to
support new hardware with long term releases. "Normal" releases may mix
packages from Debian stable with testing, unstable or even experimental
(whizzy features) but get only a short testing time.

Debian "releases when ready" but then supports that release until about
a year
after the _next_ release. 22 months to release Etch, 22 months to
release Lenny + 12 months = 56 months. Slow moving progress through
testing to release, regular point updates with security fixes.
"We demand rigidly defined areas of doubt and uncertainty" - Canonical has
those because it releases once every six months. This consistency comes at a
price: users expect new whizzy features with each release and the development
cycle is very short indeed. Long term support releases happen every 18 months
and are supported for three years on the desktop/five years on the server.
That's hard. It's _very_ hard to support new hardware with long term releases.
"Normal" releases may mix packages from Debian stable with testing, unstable or
even experimental (whizzy features) but get only a short testing time.

Debian "releases when ready" but then supports that release until about a year
after the _next_ release. 22 months to release Etch, 22 months to release Lenny
+ 12 months = 56 months. Slow moving progress through testing to release,
regular point updates with security fixes.
Line 147: Line 204:
Ubuntu may sometimes take a pragmatic attitude for "software that works"
for users. They also have the ability, which Debian does not, to enter
into commercial agreements for third party apps e.g. Oracle/VMWare.
[DFSG - not "licence just for Debian"]. Canonical benefits from Debian
idealism but it can't flow the other way :(
Ubuntu may sometimes take a pragmatic attitude for "software that works" for
users. They also have the ability, which Debian does not, to enter into
commercial agreements for third party apps e.g. Oracle/VMWare.  [DFSG - not
"licence just for Debian"]. Canonical benefits from Debian idealism but it
can't flow the other way :(
Line 155: Line 212:
You'll hear lots of views on this. Ubuntu is generally considered harder to upgrade
cleanly between releases and it may actually be quicker to reinstall.
You certainly can't skip a release (it's not even supported) so you'd need to do 8.04, 8.10,
9.04, 9.10 (for example). This is partly a consequence of short release
cycles above. Debian doesn't support skipping a release either, but
upgrades are mostly smooth, especially if you take the time to read the Release Notes.
You'll hear lots of views on this. Ubuntu is generally considered harder to
upgrade cleanly between releases and it may actually be quicker to reinstall.
You certainly can't skip a release (it's not even supported) so you'd need to
do 8.04, 8.10, 9.04, 9.10 (for example). This is partly a consequence of short
release
cycles above. Debian doesn't support skipping a release either, but
upgrades are mostly smooth, especially if you take the time to read the Release
Notes.
Line 165: Line 223:
Shuttleworth's latest interview for "Linux Format" magazine.
Its also worth reading newsgroups/fora and planet.debian.org /
planet.ubuntu.com to get a better appreciation of the similarities and
differences in approach. Debian and Ubuntu each have strengths: its a
(sometimes uneasy) symbiosis - both distributions share many of the same
developers, for example, but not necessarily end goals - but Debian
would gain as much as Ubuntu if they'll just fix their bloody bug #1 :)
Shuttleworth's latest interview for "Linux Format" magazine.  Its also worth
reading newsgroups/fora and planet.debian.org / planet.ubuntu.com to get a
better appreciation of the similarities and
differences in approach. Debian and
Ubuntu each have strengths: its a (sometimes uneasy) symbiosis - both
distributions share many of the same
developers, for example, but not
necessarily end goals - but Debian would gain as much as Ubuntu if they'll just
fix their bloody bug #1 :)
Line 175: Line 233:
Line 176: Line 235:
You can't prevent it, because this happens due to the way the kernel does device detection, but there are several methods to not let it be a problem. It seems the easiest method is to use labels instead of device names. Basically in fstab you just replace the `/dev/sda1` (or hda2 or whatever) with a `LABEL=mylabel`. If you also have problems booting (because your / partition is assigned a different device name) you will also have to edit `/boot/grub/menu.lst`. Don't edit the real stanza because your changes will be overwritten on the next kernel upgrade. Instead find the line:
You can't prevent it, because this happens due to the way the kernel does
device detection, but there are several methods to not let it be a problem. It
seems the easiest method is to use labels instead of device names. Basically in
fstab you just replace the `/dev/sda1` (or hda2 or whatever) with a
`LABEL=mylabel`. If you also have problems booting (because your / partition is
assigned a different device name) you will also have to edit
`/boot/grub/menu.lst`. Don't edit the real stanza because your changes will be
overwritten on the next kernel upgrade. Instead find the line:
Line 190: Line 257:
Another alternative to using labels is to use UUIDs. You can find the UUID of a device with blkid(8). Another alternative to using labels is to use UUIDs. You can find the UUID of a
device with blkid(8).
Line 193: Line 261:
Line 195: Line 264:
Debian is known for its robust, extensive and easy to use package system. The operations that can be performed with regard to package management are sophisticated, easily scripted, and make running Debian a relatively simple and mistake-proof experience. The following questions all deal with some aspect of the package management. Debian is known for its robust, extensive and easy to use package system. The
operations that can be performed with regard to package management are
sophisticated, easily scripted, and make running Debian a relatively simple and
mistake-proof experience. The following questions all deal with some aspect of
the package management.
Line 199: Line 272:
<<Anchor(package-bestmanager)>>
Line 201: Line 276:
While "the best" package manager is a matter of personal opinion, the Debian project and many Debian developers and users recommend aptitude. See [[http://lists.debian.org/debian-user/2004/04/msg03138.html|here]] for more details. While "the best" package manager is a matter of personal opinion, the Debian
project and many Debian developers and users recommend aptitude. See
[[http://lists.debian.org/debian-user/2004/04/msg03138.html|here]] for more
details.
Line 206: Line 284:
=== Where is the foo package?  ===
A variety of tools exists to answer this very frequent question: `apt-cache search foo bar` will return all the packages with '''both''' `foo` and `bar` in the name or description; `aptitude search foo` will return all packages with foo in the package name. These are just two of the many methods. Read `man apt-cache` or `man aptitude` as appropriate. Finally, http://packages.debian.org also features a handy search engine and don't forget your friend http://www.google.com.

=== Where is the foo package? ===

A variety of tools exists to answer this very frequent question: `apt-cache
search foo bar` will return all the packages with '''both''' `foo` and `bar` in
the name or description; `aptitude search foo` will return all packages with
foo in the package name. These are just two of the many methods. Read `man
apt-cache` or `man aptitude` as appropriate. Finally,
http://packages.debian.org also features a handy search engine and don't forget
your friend http://www.google.com.
Line 210: Line 296:
Line 212: Line 299:
This is simple: `apt-file update && apt-file search bar`. grep as appropriate. man apt-file. This is simple: `apt-file update && apt-file search bar`. grep as appropriate.
man apt-file.
Line 216: Line 304:
See previous question. If the file is already on your system dpkg should know about it (usually faster as well) See previous question. If the file is already on your system dpkg should know
about it (usually faster as well)
Line 222: Line 311:
Please note that files under /home/, /usr/local/ and a few other places are not under the control of the package management. See the Filesystem Hierarchy Standard (also available as man page hier(7) ) for an explanation of how the files are organized on your system. Please note that files under `/home/`, `/usr/local/` and a few other places are not
under the control of the package management. See the Filesystem Hierarchy
Standard (also available as man page `hier(7)` ) for an explanation of how the
files are organized on your system.
Line 225: Line 317:
Line 226: Line 319:
You really should see [[#package-search|Where is the foo package?]] above, but Debian ships with Iceweasel, a rebranded Firefox.
You really should see [[#package-search|Where is the foo package?]] above, but
Debian ships with Iceweasel, a rebranded Firefox.
Line 231: Line 326:
Line 232: Line 328:
Line 238: Line 335:
and see if that fixes your problem. Something else you can try is to (re)move your .mozilla directory or create a new user account. and see if that fixes your problem. Something else you can try is to (re)move
your `.mozilla` directory or create a new user account.
Line 242: Line 340:
Short answer: most probably with the next release. See [[#using|above]] for a quick explanation of how Debian releases work.

Long answer: Debian Developers are doing their best to package the software released upstream as soon as they consider it stable enough to be included in Debian so your package might already be available in ''testing'', ''unstable'' or ''experimental''. Unless ''testing'' is in the ''frozen'' stage (similar to a „Release Candidate”) new software is migrating from ''unstable'' to ''testing'' as soon as possible (which will then become ''stable'' on the next release), but it will never be included in the '''current''' stable release, because by definition the release must not change (apart from security fixes and some serious bugs).

If you still want to stick with ''stable'' (instead of ''testing'' or ''unstable'') your best bet is to look at http://www.backports.org for the packages you need.

You might think Debian is doing it wrong and should adopt the release policy of some other distro, but this system has proven its value over many years and it gives users a lot of choice. Various alternatives have been proposed over the years, but all of them have some disadvantages over the current scheme. Please do search the archives (also for the debian-devel and debian-project lists) before starting a new discussion over this issue.

Short answer: most probably with the next release. See [[#using|above]] for a
quick explanation of how Debian releases work.

Long answer: Debian Developers are doing their best to package the software
released upstream as soon as they consider it stable enough to be included in
Debian so your package might already be available in ''testing'', ''unstable''
or ''experimental''. Unless ''testing'' is in the ''frozen'' stage (similar to
a „Release Candidate”) new software is migrating from ''unstable'' to
''testing'' as soon as possible (which will then become ''stable'' on the next
release), but it will never be included in the '''current''' stable release,
because by definition the release must not change (apart from security fixes
and some serious bugs).

If you still want to stick with ''stable'' (instead of ''testing'' or
''unstable'') your best bet is to look at http://www.backports.org for the
packages you need.

You might think Debian is doing it wrong and should adopt the release policy of
some other distro, but this system has proven its value over many years and it
gives users a lot of choice. Various alternatives have been proposed over the
years, but all of them have some disadvantages over the current scheme. Please
do search the archives (also for the debian-devel and debian-project lists)
before starting a new discussion over this issue.
Line 251: Line 366:
You definitely like to play with fire if you got this far, but can't answer this simple question. OK, enough patronizing :) , try apt-show-versions.
You definitely like to play with fire if you got this far, but can't answer
this simple question. OK, enough patronizing :) , try apt-show-versions.
Line 254: Line 371:
Line 257: Line 375:
Line 258: Line 377:
Please see the [[http://www.debian.org/MailingLists/#codeofconduct|Code of conduct]] for Debian mailing lists. It is also helpful if you ask your questions in a [[http://www.catb.org/~esr/faqs/smart-questions.html|smart way]] and answer by [[http://www.netmeister.org/news/learn2quote.html|quoting]] properly.
Please see the [[http://www.debian.org/MailingLists/#codeofconduct|Code of
conduct]] for Debian mailing lists. It is also helpful if you ask your
questions in a [[http://www.catb.org/~esr/faqs/smart-questions.html|smart way]]
and answer by [[http://www.netmeister.org/news/learn2quote.html|quoting]]
properly.
Line 261: Line 385:
Line 262: Line 387:
=== I asked my question according to the directions written at the "How should I post" question, but I still don't get an answer ===
I don't think you '''really''' read [[http://www.catb.org/~esr/faqs/smart-questions.html|this faq]] referenced [[#posting-howto|above]] (this question is anwered there, I just double-checked :) ).

=== I asked my question according to the directions written at
the "How should I post" question, but I still don't get an answer ===

I don't think you '''really''' read
[[http://www.catb.org/~esr/faqs/smart-questions.html|this faq]] referenced
[[#posting-howto|above]] (this question is anwered there, I just double-checked
:) ).
Line 266: Line 397:
Line 267: Line 399:
Debian has a policy of open mailing lists. This means most lists are open for anyone to write to (the occasional spam resulting from this is unavoidable, but only a minor inconvenience - the list has '''excellent filters'''). However, list subscribers can not guess if you are subscribed or not, so you should request replies to be CC'd to you (or set `Reply-To` accordingly).
Debian has a policy of open mailing lists. This means most lists are open for
anyone to write to (the occasional spam resulting from this is unavoidable, but
only a minor inconvenience - the list has '''excellent filters'''). However,
list subscribers can not guess if you are subscribed or not, so you should
request replies to be CC'd to you (or set `Reply-To` accordingly).
Line 270: Line 407:
=== Help! My e-mail address is available in your list archives for the spam-bots to harvest/Why aren't e-mail addresses scrambled? ===
Such a measure does not really help to fight the spam, just one symptom. See http://www.interhack.net/pubs/munging-harmful for a detailed explanation.

=== Help! My e-mail address is available in your list archives for the spam-bots
to harvest/Why aren't e-mail addresses scrambled? ===

Such a measure does not really help to fight the spam, just a
symptom. See http://www.interhack.net/pubs/munging-harmful for a detailed
explanation.
Line 274: Line 416:
Line 275: Line 418:
Short answer: you can't. Even if the archive administrators would do it for the official Debian archives, this list is available in several other places (gmane, googlegroups, ...) over which the Debian Project has no control. See also the [[http://www.debian.org/MailingLists/#disclaimer|official policy]] for more info.
Short answer: you can't. Even if the archive administrators would do it for the
official Debian archives, this list is available in several other places
(gmane, googlegroups, ...) over which the Debian Project has no control. See
also the [[http://www.debian.org/MailingLists/#disclaimer|official policy]] for
more info.
Line 278: Line 426:
Line 279: Line 428:
The debian-user mailing list is a very high traffic list, you should expect to get around 150 mails '''per day''', but there are ways to cope with it:
 * setup a filter to move all list mail to a dedicated folder (if you want it all) or even delete all list mail except specific threads (ex. the ones initiated by you)
 *
use alternatives:
   *
gmane is a mail-to-news gateway with an alternative nice web interface (subscription required?)
   * googlegroups also
carries debian-user if you prefer their interface (subscription required)
   * debian-user is also available as a newsgroup (directly or via gmane)
   * read
the archives (but beware, it can take a while longer until a mail shows up there)
 *
just unsubscribe. If you only want to receive answers to your posts you can ask for a CC (or set `Reply-To` accordingly)
 * use a decent mail
client. It should support at least some way of threading (and sorting if not done by other means) and [[ReplyToListEmailClients|reply-to-list]] (if you plan to participate in discussions).

The debian-user mailing list is a very high traffic list, you should expect to
get around 150 mails '''per day''', but there are ways to cope with it:

* setup a filter to move all list mail to a dedicated folder (if you want it
 *
all) or even delete all list mail except specific threads (ex. the ones
 *
initiated by you) use alternatives: gmane is a mail-to-news gateway with an
 *
alternative nice web interface (subscription required?) googlegroups also
 *
carries debian-user if you prefer their interface (subscription required)
 * debian-user is also available as a newsgroup (directly or via gmane) read
 *
the archives (but beware, it can take a while longer until a mail shows up
 *
there) just unsubscribe. If you only want to receive answers to your posts
 *
you can ask for a CC (or set `Reply-To` accordingly) use a decent mail
 *
client. It should support at least some way of threading (and sorting if not
 *
done by other means) and [[ReplyToListEmailClients|reply-to-list]] (if you
 *
plan to participate in discussions).
Line 290: Line 446:
Line 291: Line 448:
Line 302: Line 460:
Line 303: Line 462:
Short answer: it's against the standards. See [[http://www.unicom.com/pw/reply-to-harmful.html|this]] document for a thorough explanation. In case your e-mail client doesn't support [[ReplyToListEmailClients|List-reply]] then please use Reply-to-all and delete all but the list address.
Short answer: it's against the standards. See
[[http://www.unicom.com/pw/reply-to-harmful.html|this]] document for a thorough
explanation. In case your e-mail client doesn't support
[[ReplyToListEmailClients|List-reply]] then please use Reply-to-all and delete
all but the list address.
Line 306: Line 470:
Line 307: Line 472:
Try subscribing to the [[http://lists.debian.org/whitelist/|whitelist]]. See also [[#posting-gmail|this question]] in case you post from a gmail account.
Try subscribing to the [[http://lists.debian.org/whitelist/|whitelist]]. See
also [[#posting-gmail|this question]] in case you post from a gmail account.
Line 310: Line 477:
=== I'm posting via gmail's servers, but I never receive my own posts (other list mail is fine) ===
Gmail has a somewhat different (as in against the standards) view of how a mail server should behave. Because there is already a copy of your mail in the '''Sent''' folder the incoming copy from the mailing list is discarded. If you still want to use Gmail for posting here are a few possible workarounds:
 * configure your mail client to save outgoing messages to the same folder. Most (all?) mail clients should be able to do this per folder.
 * use a different account for receiving list mail. Most Debian lists (including debian-user) are open for anyone to post, so you don't need to be subscribed to be able to post (you could however subscribe to the [[#posting-whitelist|whitelist]]).
It seems Gmail considers this to be a feature and is not willing to change it, although requested by many users. You could try writing them about this as well, maybe they will eventually listen.

=== I'm posting via gmail's servers, but I never receive my own posts
(other list mail is fine) ===

Gmail has a somewhat different view of how a mail server should behave. Because
there is already a copy of your mail in the '''Sent''' folder the incoming copy
from the mailing list is silently
discarded. If you still want to use Gmail for
posting here are a few possible workarounds:

* configure your mail client to save outgoing messages to the same folder.
 *
Most (all?) mail clients should be able to do this per folder.  use a
 * different account for receiving list mail. Most Debian lists (including
 *
debian-user) are open for anyone to post, so you don't need to be subscribed
 *
to be able to post (you could however subscribe to the
 *
[[#posting-whitelist|whitelist]]).

It seems Gmail considers this to be a feature and is not willing to change it,
although requested by many users. You could try writing them about this as
well, maybe they will eventually listen.

Translation(s): none

(!) Discussion


This page is meant to collect frequently asked questions from the debian-user mailing list. The contents are licenced under the terms of GPLv2 or, in the event a DFSG compatible licence is applied to wiki.debian.org at large, then under that licence. Posting material to this page is an acceptance of this.

Why bother

Why should I post to this list? I want to ask the developer/post to debian-devel/file a bug.

Of course, you are free to do this. Almost all debian lists (including debian-devel) are open for anyone to post and Debian encourages users to file bugs in the Debian Bug Tracking System (BTS). BUT, please consider following points first:

  • Make 100% sure your problem needs direct attention of developers.

  • Remember, Debian is created by volunteers in their spare time. Distracting
  • them with other problems will leave less time to do actual work, like
  • solving known bugs, package new versions of software we are all waiting for,
  • packaging software not yet present in Debian and improving or creating
  • Debian specific software. Even if you know you have a really difficult
  • problem, debian-user is read by some very knowledgeable people

  • (including some Debian developers), and they might have a solution for your
  • problem. Some problems are caused just by misconfiguration. Sometimes even
  • the most experienced people can do stupid things. Having other people look
  • over your problem may help. Make sure your problem is not known. That means
  • you should search the archives of debian-user (or other relevant lists) and
  • especially the BTS. Chances are somebody else has experienced the same (or
  • similar) problem and workarounds may be known. Even if you searched
  • thoroughly, you should post to debian-user first (stating what you already
  • tried/researched).

If you considered all above points and still want to address debian-devel, then please make sure:

  • your problem is not specific to a package (you could file a bug instead) it
  • hasn't been discussed yet (you did search the archives, right?) you are
  • addressing the right list (ex. legal stuff should go to debian-legal,
  • website specific to debian-www, ...)

In case you have doubts just post to debian-user, sometimes answers come within minutes.

Using Debian

Should I be running Testing/Unstable(Sid) instead of Stable/Testing?

This is something that you as a user and administrator of your system have to decide for yourself. If you just need a few newer packages try http://www.backports.org before considering an upgrade. If you have Debian on a desktop machine testing might be an option, but it's not really recommended for production machines. If you want all the newest software Debian can provide and don't mind/can handle breakage then you could try unstable. If you are in doubt always use stable. Each Debian distribution has its pros and cons. Here are some:

Stable
  • released approx. every 1.5 years. has security support and occasional
  • bug-fixes (via the security archive, proposed-updates archive and point
  • releases). very stable, thoroughly tested, recommended for environments
  • where frequent changes are not desired and high uptimes are required. can
  • have oldish software and may lack support for very new hardware.

    See DebianStable for more informations ...

Testing
  • testing is slowly evolving to become the next Stable release, but until
  • released it is still testing ground. As the release approaches (testing
  • freeze) it becomes more and more like a newer stable release (with all pros
  • and cons). packages have already received some testing in unstable.
  • security support. bug fixes have to go through unstable first (usually 10
  • days, but can take longer). Because of this any breakage might take at least
  • 10 days to be fixed. requires some skill to maintain.

    See DebianTesting for more informations ...

Unstable (a.k.a. Sid, a.k.a Still In Development, the character in Toy Story who broke toys)
  • contains packages uploaded by the developers for the next release, but will
  • never be released. Instead, packages will usually migrate to testing if no
  • release-critical bugs are found in 10 days (and there are no dependency
  • problems). most of the times has quite recent software or even bleeding
  • edge. no security support similar to stable or testing, but updated
  • packages should also incorporate security fixes. changes can/do happen even
  • daily. serious breakage can (and will!) occur; requires good skills to
  • maintain, but good for learning if you don't mind the downtime.

    See DebianSid and DebianUnstable for more informations ...

Experimental

This is not a regular distribution (you cannot run on experimental), but it is mentioned here for completeness.

  • a place for maintainers to upload packages which are not suitable for
  • unstable, but still need a wider audience for testing. no security support
  • and some packages can stay here for long times without any updates. usage
  • is not recommended unless you really know what you are doing.

    See DebianExperimental for more informations ...

How dangerous is it to run a mixed system?

That depends on how many and what packages you are using, but it can be more dangerous than running pure unstable. Installing packages from different releases can cause complex problems which are less likely to occur with packages from a single release. One example is that existing packages may become uninstalled due to internal restructuring of central components within the testing or unstable branches.

Try backports first. If you can't find what you need there you can also backport a package yourself.

How different is Ubuntu from Debian?

There are lots of differences: some big, some small but all may be significant.

Rationale/design goals

Packages in Ubuntu main are very highly polished, very well maintained and Canonical/Ubuntu go the extra mile to make the experience easy for the user. That comes at one or more of several costs:

Choice

Lack of choice - you get one mail client rather than a choice of several "out of the box", for example. Choices are made for you - its an issue of supportability. Debian offers you more flexibility at the price of complexity or being willing to support your choices.

Architectures

Lack of architectures: if you're not on Intel/AMD64 or, possibly, ARM/Sparc/PPC (depending on release) - you can't run Ubuntu. Debian running on 11 or so architectures does mean that a) the process is sometimes slow b) the code gets debugged c) is made portable/fixes are contributed upstream.

Developer/user ratio

Canonical has relatively few paid developers, a highly motivated volunteeer developer community, a much larger community advocacy and marketing budget and a vast number of new users. This does mean that their developers are massively outnumbered by their users and priorities have to be set. Packages in universe/multiverse may therefore receive less attention than those in main in Ubuntu.

At least in theory, every package in Debian is equal and has a known named maintainer who takes an interest :) It does mean that Debian does much of the heavy lifting of packaging and initial support for out of the way packages - it also means that, if I want support for R and CRAN, for example, I'd go straight to Debian because the maintainer has a personal and professional interest for seeing it work well as an integrated system.

Release cycles

"We demand rigidly defined areas of doubt and uncertainty" - Canonical has those because it releases once every six months. This consistency comes at a price: users expect new whizzy features with each release and the development cycle is very short indeed. Long term support releases happen every 18 months and are supported for three years on the desktop/five years on the server. That's hard. It's _very_ hard to support new hardware with long term releases. "Normal" releases may mix packages from Debian stable with testing, unstable or even experimental (whizzy features) but get only a short testing time.

Debian "releases when ready" but then supports that release until about a year after the _next_ release. 22 months to release Etch, 22 months to release Lenny + 12 months = 56 months. Slow moving progress through testing to release, regular point updates with security fixes.

Freeness vs. pragmatism

Ubuntu may sometimes take a pragmatic attitude for "software that works" for users. They also have the ability, which Debian does not, to enter into commercial agreements for third party apps e.g. Oracle/VMWare. [DFSG - not "licence just for Debian"]. Canonical benefits from Debian idealism but it can't flow the other way :(

Upgrades between releases

You'll hear lots of views on this. Ubuntu is generally considered harder to upgrade cleanly between releases and it may actually be quicker to reinstall. You certainly can't skip a release (it's not even supported) so you'd need to do 8.04, 8.10, 9.04, 9.10 (for example). This is partly a consequence of short release cycles above. Debian doesn't support skipping a release either, but upgrades are mostly smooth, especially if you take the time to read the Release Notes.

Summary

All of this is very well explained by The Official Ubuntu Book and Mark Shuttleworth's latest interview for "Linux Format" magazine. Its also worth reading newsgroups/fora and planet.debian.org / planet.ubuntu.com to get a better appreciation of the similarities and differences in approach. Debian and Ubuntu each have strengths: its a (sometimes uneasy) symbiosis - both distributions share many of the same developers, for example, but not necessarily end goals - but Debian would gain as much as Ubuntu if they'll just fix their bloody bug #1 :)

My harddisks/usb sticks/external drives don't always have the same device name. How can I prevent this from happening?

You can't prevent it, because this happens due to the way the kernel does device detection, but there are several methods to not let it be a problem. It seems the easiest method is to use labels instead of device names. Basically in fstab you just replace the /dev/sda1 (or hda2 or whatever) with a LABEL=mylabel. If you also have problems booting (because your / partition is assigned a different device name) you will also have to edit /boot/grub/menu.lst. Don't edit the real stanza because your changes will be overwritten on the next kernel upgrade. Instead find the line:

# kopt=root=/dev/hda1

and replace it with

# kopt=root=LABEL=my_root_label

After you are done you must run update-grub as root.

Another alternative to using labels is to use UUIDs. You can find the UUID of a device with blkid(8).

Software Packages

Debian is known for its robust, extensive and easy to use package system. The operations that can be performed with regard to package management are sophisticated, easily scripted, and make running Debian a relatively simple and mistake-proof experience. The following questions all deal with some aspect of the package management.

Which is the best package manager?

While "the best" package manager is a matter of personal opinion, the Debian project and many Debian developers and users recommend aptitude. See here for more details.

Where is the foo package?

A variety of tools exists to answer this very frequent question: `apt-cache search foo bar will return all the packages with '''both''' foo and bar` in the name or description; aptitude search foo will return all packages with foo in the package name. These are just two of the many methods. Read `man apt-cache or man aptitude` as appropriate. Finally, http://packages.debian.org also features a handy search engine and don't forget your friend http://www.google.com.

Program foo is looking for (or lacking) file bar. Where is it?

This is simple: apt-file update && apt-file search bar. grep as appropriate. man apt-file.

What package contains file foo?

See previous question. If the file is already on your system dpkg should know about it (usually faster as well)

$ dpkg -S /path/to/foo

Please note that files under /home/, /usr/local/ and a few other places are not under the control of the package management. See the Filesystem Hierarchy Standard (also available as man page hier(7) ) for an explanation of how the files are organized on your system.

Does Debian have Firefox/What is Iceweasel?

You really should see Where is the foo package? above, but Debian ships with Iceweasel, a rebranded Firefox.

Firefox/Iceweasel has strange problems (segfaults, crashes, ...)

First try running with all extensions disabled by running

$ iceweasel -safe-mode

and see if that fixes your problem. Something else you can try is to (re)move your .mozilla directory or create a new user account.

Ubuntu/some other distro already has a newer kernel/Gnome/KDE/Firefox/other. When will Debian have it?

Short answer: most probably with the next release. See above for a quick explanation of how Debian releases work.

Long answer: Debian Developers are doing their best to package the software released upstream as soon as they consider it stable enough to be included in Debian so your package might already be available in testing, unstable or experimental. Unless testing is in the frozen stage (similar to a „Release Candidate”) new software is migrating from unstable to testing as soon as possible (which will then become stable on the next release), but it will never be included in the current stable release, because by definition the release must not change (apart from security fixes and some serious bugs).

If you still want to stick with stable (instead of testing or unstable) your best bet is to look at http://www.backports.org for the packages you need.

You might think Debian is doing it wrong and should adopt the release policy of some other distro, but this system has proven its value over many years and it gives users a lot of choice. Various alternatives have been proposed over the years, but all of them have some disadvantages over the current scheme. Please do search the archives (also for the debian-devel and debian-project lists) before starting a new discussion over this issue.

I am running a mixed system. How can I find out what packages are from which distribution?

You definitely like to play with fire if you got this far, but can't answer this simple question. OK, enough patronizing :) , try apt-show-versions.

Posting on debian-user

How should I post/reply to debian-user?

Please see the [[http://www.debian.org/MailingLists/#codeofconduct|Code of conduct]] for Debian mailing lists. It is also helpful if you ask your questions in a smart way and answer by quoting properly.

=== I asked my question according to the directions written at the "How should I post" question, but I still don't get an answer ===

I don't think you really read this faq referenced above (this question is anwered there, I just double-checked :) ).

Should I be subscribed to post to debian-user?

Debian has a policy of open mailing lists. This means most lists are open for anyone to write to (the occasional spam resulting from this is unavoidable, but only a minor inconvenience - the list has excellent filters). However, list subscribers can not guess if you are subscribed or not, so you should request replies to be CC'd to you (or set Reply-To accordingly).

=== Help! My e-mail address is available in your list archives for the spam-bots to harvest/Why aren't e-mail addresses scrambled? ===

Such a measure does not really help to fight the spam, just a symptom. See http://www.interhack.net/pubs/munging-harmful for a detailed explanation.

How can I get my postings/e-mail removed from the archives?

Short answer: you can't. Even if the archive administrators would do it for the official Debian archives, this list is available in several other places (gmane, googlegroups, ...) over which the Debian Project has no control. See also the official policy for more info.

I subscribed the list, but my mailbox is flooded with mail

The debian-user mailing list is a very high traffic list, you should expect to get around 150 mails per day, but there are ways to cope with it:

  • setup a filter to move all list mail to a dedicated folder (if you want it
  • all) or even delete all list mail except specific threads (ex. the ones
  • initiated by you) use alternatives: gmane is a mail-to-news gateway with an
  • alternative nice web interface (subscription required?) googlegroups also
  • carries debian-user if you prefer their interface (subscription required)
  • debian-user is also available as a newsgroup (directly or via gmane) read
  • the archives (but beware, it can take a while longer until a mail shows up
  • there) just unsubscribe. If you only want to receive answers to your posts
  • you can ask for a CC (or set Reply-To accordingly) use a decent mail

  • client. It should support at least some way of threading (and sorting if not
  • done by other means) and reply-to-list (if you

  • plan to participate in discussions).

What is top-posting (and why shouldn't I do it)?

Both questions can be answered with this example (seen in some sig):

A: Because it messes up the way you read

Q: Why is top-posting bad?

A: Writing your answer before the question

Q: What is top-posting?

Why doesn't this list facilitate easy replies to the list (a.k.a. reply-to-munging)?

Short answer: it's against the standards. See this document for a thorough explanation. In case your e-mail client doesn't support List-reply then please use Reply-to-all and delete all but the list address.

My posts are considered spam and rejected (or never show up)

Try subscribing to the whitelist. See also this question in case you post from a gmail account.

=== I'm posting via gmail's servers, but I never receive my own posts (other list mail is fine) ===

Gmail has a somewhat different view of how a mail server should behave. Because there is already a copy of your mail in the Sent folder the incoming copy from the mailing list is silently discarded. If you still want to use Gmail for posting here are a few possible workarounds:

  • configure your mail client to save outgoing messages to the same folder.
  • Most (all?) mail clients should be able to do this per folder. use a
  • different account for receiving list mail. Most Debian lists (including
  • debian-user) are open for anyone to post, so you don't need to be subscribed
  • to be able to post (you could however subscribe to the
  • whitelist).

It seems Gmail considers this to be a feature and is not willing to change it, although requested by many users. You could try writing them about this as well, maybe they will eventually listen.


FAQs