| 1 | Frequently Asked Questions about base-files |
|---|
| 2 | =========================================== |
|---|
| 3 | |
|---|
| 4 | * Questions about "profile.d": |
|---|
| 5 | |
|---|
| 6 | Q. Why does Debian not have a "profile.d" directory, like other distributions? |
|---|
| 7 | |
|---|
| 8 | A. Because no Debian package needs it. Debian policy says: "A program |
|---|
| 9 | must not depend on environment variables to get reasonable defaults". |
|---|
| 10 | This policy has been very successful so far. If the default install |
|---|
| 11 | had a profile.d, people might think it's ok to use it for a Debian |
|---|
| 12 | package, when in fact policy does not support such thing. |
|---|
| 13 | |
|---|
| 14 | Q. Ok, but I still think it would still be a nice thing to have, would |
|---|
| 15 | not make sense to have a profile.d by default, even if no Debian |
|---|
| 16 | package uses it? |
|---|
| 17 | |
|---|
| 18 | A. No. As explained before, there is the risk of assuming that it's |
|---|
| 19 | "officially supported". If you need a profile.d directory, you may |
|---|
| 20 | still create one in your machine and modify your /etc/profile |
|---|
| 21 | accordingly to enable it. Since this is a configuration file, |
|---|
| 22 | its contents will be preserved in upgrades. |
|---|
| 23 | |
|---|
| 24 | Q. Ok, but if I do that I will have to merge my changes every time |
|---|
| 25 | the /etc/profile provided by base-files changes. |
|---|
| 26 | |
|---|
| 27 | A. That should not be a big problem. The default /etc/profile provided |
|---|
| 28 | by base-files is quite minimal on purpose, and it is not expected to |
|---|
| 29 | change drastically from one Debian release to the next one. |
|---|
| 30 | |
|---|
| 31 | |
|---|
| 32 | * Questions about /etc/issue and /etc/debian_version: |
|---|
| 33 | |
|---|
| 34 | Q. I upgraded my system to the testing distribution and now my /etc/issue |
|---|
| 35 | says "lenny/sid". Should it not read "lenny" or "testing"? |
|---|
| 36 | |
|---|
| 37 | Q. I upgraded my system to the unstable distribution and now my /etc/issue |
|---|
| 38 | says "lenny/sid". Should it not read "sid" or "unstable"? |
|---|
| 39 | |
|---|
| 40 | A. You obviously do not understand how the testing distribution works. |
|---|
| 41 | Packages uploaded for unstable reach testing after ten days, provided |
|---|
| 42 | they are built for every released architecture, have no RC-bugs and |
|---|
| 43 | their dependencies may be met in testing. You should consider the |
|---|
| 44 | testing and unstable distributions as two sides of the same coin. |
|---|
| 45 | Since the base-files package in testing was initially uploaded for |
|---|
| 46 | unstable, the only sensible /etc/issue to have is one that is both |
|---|
| 47 | valid for testing and unstable, hence "lenny/sid" (or whatever is |
|---|
| 48 | appropriate). |
|---|
| 49 | |
|---|
| 50 | Q. Why "lenny/sid" and not "testing/unstable" as usual? |
|---|
| 51 | |
|---|
| 52 | A. The codename is a little bit more informative, as the meaning of |
|---|
| 53 | "testing" changes over time. |
|---|
| 54 | |
|---|
| 55 | Q. Ok, but how do I know which distribution I'm running? |
|---|
| 56 | |
|---|
| 57 | A. If you are running testing or unstable, then /etc/debian_version is |
|---|
| 58 | not a reliable way to know that anymore. Looking at the contents of |
|---|
| 59 | your /etc/apt/sources.list file is probably a much better way. |
|---|
| 60 | |
|---|
| 61 | |
|---|
| 62 | * Other questions: |
|---|
| 63 | |
|---|
| 64 | Q. Why isn't license "foo" included in common-licenses? |
|---|
| 65 | |
|---|
| 66 | A. I delegate such decisions to the policy group. If you want to |
|---|
| 67 | propose a new license you should make a policy proposal to modify the |
|---|
| 68 | paragraph in policy saying "Packages distributed under the UCB BSD |
|---|
| 69 | license, Artistic license, GNU GPL and GNU LGPL should refer to the |
|---|
| 70 | files in /usr/share/common-licenses". The way of doing this is |
|---|
| 71 | explained in the debian-policy package. As usual, you should always |
|---|
| 72 | take a look at already reported bugs against debian-policy before |
|---|
| 73 | submitting a new one. |
|---|
| 74 | |
|---|
| 75 | Q. I upgraded from woody to sarge. Should my system be FHS-compliant now? |
|---|
| 76 | |
|---|
| 77 | A. Achieving FHS compliance by upgrading would be tricky and prone to |
|---|
| 78 | error in certain cases, so it is not a goal of base-files, nor it is |
|---|
| 79 | planned to be. By default, some "mandatory" directories (like /opt, |
|---|
| 80 | /srv or /media) are only created in the first install (performed by |
|---|
| 81 | debootstrap), to keep the code as simple as possible, follow the |
|---|
| 82 | principle of least surprise on upgrades, and also to give people the |
|---|
| 83 | freedom to remove those directories without them being created again |
|---|
| 84 | when base-files is upgraded. Therefore, if you are running any sort of |
|---|
| 85 | compliance tests, you should do it on newly installed systems only. |
|---|
| 86 | |
|---|
| 87 | |
|---|
| 88 | Santiago Vila <sanvila@debian.org> |
|---|