Proper setup

This commit is contained in:
2026-04-03 00:20:46 -07:00
parent d82d9a923d
commit b05a25426c
10 changed files with 42 additions and 1815 deletions
+24
View File
@@ -0,0 +1,24 @@
NOTICE — Third-Party Source Acknowledgement
============================================
This package is a fork of the Debian Project's "base-files" package,
originally created by Ian Murdock and Bruce Perens, and maintained by
the Debian base system team.
Original project:
Name: base-files
Source: https://salsa.debian.org/debian/base-files
Authors: Ian Murdock <imurdock@debian.org>,
Bruce Perens <bruce@pixar.com>,
Santiago Vila <sanvila@debian.org>,
and contributors to the Debian Project.
This fork replaces Debian branding with VesperOS identity files
(os-release, issue, issue.net, vesper_version, origins). All original
copyright notices have been retained as required by the GPL-2+ licence
under which the original work was distributed.
VesperOS modifications:
Copyright 2025-2026 VesperOS Desktop Team <contact@oxmc.me>
For full copyright and licence details see debian/copyright.
Vendored
-9
View File
@@ -1,9 +0,0 @@
base-files (13.2) unstable; urgency=medium
By default, snippets for Bourne and Bourne-compatible shells (*.sh)
in /etc/profile.d will only be sourced by /etc/profile if they
conform to a sensible regexp including only some ASCII characters,
as it already happens with cron entries and the like. Previously,
the behaviour was not really well defined.
-- Santiago Vila <sanvila@debian.org> Fri, 03 May 2024 18:04:00 +0200
-106
View File
@@ -1,106 +0,0 @@
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>
-29
View File
@@ -1,29 +0,0 @@
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>
-2
View File
@@ -1,2 +0,0 @@
debian/README
debian/README.FHS
+5 -1659
View File
File diff suppressed because it is too large Load Diff
+1 -1
View File
@@ -1,7 +1,7 @@
Source: base-files
Section: admin
Priority: required
Maintainer: Seth Olivarez <me@oxmc.me>
Maintainer: VesperOS Desktop Team <contact@oxmc.me>
Standards-Version: 4.7.2
Build-Depends: debhelper-compat (= 13), debhelper (>= 13.10~)
Vcs-Git: https://git.oxmc.me/Chillcraft/base-files.git
+8 -5
View File
@@ -1,11 +1,14 @@
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Contact: VesperOS Desktop Team <contact@oxmc.me>
Source: https://git.oxmc.me/Chillcraft/base-files
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 is a fork of the Debian Project's base-files package.
Original source: https://salsa.debian.org/debian/base-files
See NOTICE.txt for full acknowledgement.
.
This package was first put together by Bruce Perens <Bruce@Pixar.com>,
from his own sources.
The original Debian base-files package was written by Ian Murdock
<imurdock@debian.org> and Bruce Perens <bruce@pixar.com>, and first
put together by Bruce Perens <Bruce@Pixar.com> from his own sources.
Files: *
Copyright: (C) 1995-2011 Software in the Public Interest
+2 -2
View File
@@ -63,7 +63,7 @@ endif
ln -s ../usr/lib/os-release $(DESTDIR)/etc/os-release
override_dh_installchangelogs:
dh_installchangelogs --no-trim
dh_installchangelogs
override_dh_link:
dh_link -X os-release
@@ -73,7 +73,7 @@ override_dh_link:
done
override_dh_compress:
dh_compress -X README
dh_compress
override_dh_fixperms:
dh_fixperms
+2 -2
View File
@@ -1,7 +1,7 @@
The programs included with the Violet system are free software;
The programs included with the VesperOS system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Violet comes with ABSOLUTELY NO WARRANTY, to the extent
VesperOS comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.