debian/README - base-files - Git at Google

 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>
	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>