+++ /dev/null
-Frequently Asked Questions about base-files
-===========================================
-
-* Questions about /etc/issue and /etc/debian_version:
-
-Q. I upgraded my system to the testing distribution and now my /etc/issue
-says "buster/sid". Should it not read "buster" or "testing"?
-
-Q. I upgraded my system to the unstable distribution and now my /etc/issue
-says "buster/sid". Should it not read "sid" or "unstable"?
-
-A. That would be nice, but it is not possible because of the way the
-testing distribution works. Packages uploaded for unstable reach
-testing after ten days, provided they are built for every released
-architecture, have no RC-bugs and their dependencies may be met in
-testing. You should consider the testing and unstable distributions as
-two sides of the same coin. Since the base-files package in testing
-was initially uploaded for unstable, the only sensible /etc/issue to
-have is one that is both valid for testing and unstable, hence
-"buster/sid" (or whatever is appropriate).
-
-Q. Why "buster/sid" and not "testing/unstable" as it used to be?
-
-A. The codename is a little bit more informative, as the meaning of
-"testing" changes over time.
-
-Q. Ok, but how do I know which distribution I'm running?
-
-A. If you are running testing or unstable, then /etc/debian_version is
-not a reliable way to know that anymore. Looking at the contents of
-your /etc/apt/sources.list file is probably a much better way.
-
-Q. There is a new point release and I've just upgraded my system.
-The /etc/debian_version file now says 8.x but /etc/issue still says 8.
-Is this ok?
-
-A. Yes. The release managers asked me not to touch /etc/issue, as that's
-a file which is often customized by the user. The /etc/debian_version file,
-on the other side, is updated at every point release, so that the exact
-Debian version is shown when used by tools like reportbug.
-
-* Other questions:
-
-Q. After upgrading my system recently, I noticed that some files from
-base-files do not match the ones which are installed on a fresh install
-of squeeze. Should I not be warned about that?
-
-A. Those files are configuration files, so they are completely under
-the control of the system admin. The files installed by base-files are
-just defaults. Changes in the default files are not important enough
-to warn the user, as it is also policy that prompting should be
-reduced to a minimum. This is also the reason they are not handled via
-dpkg's conffile mechanism.
-
-In either case, if you want to "upgrade" those files, just look at the
-postinst for base-files (i.e. /var/lib/dpkg/info/base-files.postinst)
-and you will see how they are created and where their master copies are:
-
- install_from_default /usr/share/base-files/dot.profile /root/.profile
- install_from_default /usr/share/base-files/dot.bashrc /root/.bashrc
- install_from_default /usr/share/base-files/profile /etc/profile
- install_from_default /usr/share/base-files/motd /etc/motd
-
-So, if you want your system to be as similar as possible to a newly
-installed squeeze system, you might want to sync these files manually.
-
-Note 1: Since base-files version 6.10, /etc/profile is automatically
-upgraded if it has not been modified from a previous default.
-
-Note 2: The file /etc/nsswitch.conf has been moved to libc-bin.
-
-
-Q. Why isn't license "foo" included in common-licenses?
-
-A. I delegate such decisions to the policy group. If you want to
-propose a new license you should make a policy proposal to modify the
-paragraph in policy saying "Packages distributed under the Apache
-license (version 2.0), the Artistic license, the GNU GPL (versions 1,
-2, or 3), the GNU LGPL (versions 2, 2.1, or 3), and the GNU FDL
-(versions 1.2 or 1.3) should refer to the corresponding files under
-/usr/share/common-licenses". The way of doing this is explained in the
-debian-policy package. As usual, you should always take a look at
-already reported bugs against debian-policy before submitting a new
-one.
-
-Q. I upgraded from woody to sarge. Should my system be FHS-compliant now?
-
-A. Achieving FHS compliance by upgrading would be tricky and prone to
-error in certain cases, so it is not a goal of base-files, nor it is
-planned to be. By default, some "mandatory" directories (like /opt,
-/srv or /media) are only created in the first install (performed by
-debootstrap), to keep the code as simple as possible, follow the
-principle of least surprise on upgrades, and also to give people the
-freedom to remove those directories without them being created again
-when base-files is upgraded. Therefore, if you are running any sort of
-compliance tests, you should do it on newly installed systems only.
-
-
-Santiago Vila <sanvila@debian.org>
OSDN Git Service
