EVERYTHING FROM THE OTHER REPO

2026-07-29 03:36:26 +03:00
parent 6777ea96db
commit 92a6ae42f5
4426 changed files with 1696506 additions and 2 deletions
@@ -0,0 +1 @@
+README
@@ -0,0 +1,106 @@
+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 "forky/sid". Should it not read "forky" or "testing"?
+
+Q. I upgraded my system to the unstable distribution and now my /etc/issue
+says "forky/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
+"forky/sid" (or whatever is appropriate).
+
+Q. Why "forky/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 13.x but /etc/issue still says 13.
+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.
+
+Q. My system (when I do "dpkg -s base-files") shows /etc/profile as
+an "obsolete conffile". Is this ok?
+
+A. Yes. The file was handled by base-files as a conffile in the dpkg sense
+in the past, so dpkg may consider the file as an obsolete conffile.
+There is currently not a way to tell dpkg to unregister it as a conffile
+without removing it, so the best approach for now is to do nothing about it.
+
+Santiago Vila <sanvila@debian.org>
@@ -0,0 +1,29 @@
+The FHS standard specifies /var/mail as the mail spool, but it also says
+/var/mail may be a symbolic link to another directory, and there is no
+requirement to physically move the mail spool to this location.
+
+Therefore, no package will move files around from one location to another
+on upgrades, and /var/mail will be the real directory only in newly
+installed systems.
+
+Since /var/spool/mail has been in use for several years now, we need
+also to provide backwards compatibility for some time yet.
+
+So, to summarize:
+
+* New systems (Debian 2.2 or later) will have /var/mail as a real
+directory and /var/spool/mail as a symlink to it.
+
+* Upgraded systems will have /var/spool/mail as the real directory
+and /var/mail as a symlink to it.
+
+
+People upgrading from previous releases who prefer the new physical
+location /var/mail over the old one may do the required changes in their
+systems if they do it with extreme care and know what they are doing. The
+packages in charge of ensuring that /var/mail exists (currently, libc6 and
+base-files) will not touch it at all if it already exists as a directory
+or a symlink.
+
+
+Santiago Vila <sanvila@debian.org>
@@ -0,0 +1,37 @@
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This is the Debian prepackaged version of the Debian Base System
+ Miscellaneous files. These files were written by Ian Murdock
+ <imurdock@debian.org> and Bruce Perens <bruce@pixar.com>.
+ .
+ This package was first put together by Bruce Perens <Bruce@Pixar.com>,
+ from his own sources.
+
+Files: *
+Copyright: (C) 1995-2011 Software in the Public Interest
+License: GPL-2+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+ .
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ .
+ On Debian systems, the complete text of the GNU General
+ Public License can be found in `/usr/share/common-licenses/GPL'.
+Comment:
+ The Artistic License in /usr/share/common-licenses is the one coming
+ from Perl and its SPDX name is "Artistic License 1.0 (Perl)".
+
+Files: licenses/GFDL-*
+       licenses/GPL-*
+       licenses/LGPL-*
+Copyright: 1989-2008 Free Software Foundation, Inc.
+License: verbatim
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+Comment:
+ The GNU licenses in /usr/share/common-licenses were taken from ftp.gnu.org.