Recommends vs Depends[edit]

This is about Recommends: vs Depends: in context of debian/control.

debian/control: There are separate meta packages ^[archive] for dependencies and recommended packages. For example:

anon-shared-packages-dependencies
anon-shared-packages-recommended

The reason for this is, because if we used the Recommends: field for Whonix ™ meta packages (those who pull the required Debian upstream packages for creating Whonix ™), we could not install them using apt with --install-recommends, which is apt's default option, because that would also install packages recommend by any dependency we install.

On the other hand, if we installed using apt --no-install-recommends, the packages Whonix ™ meta packages recommends, will not get installed.

Therefore splitting them into packages suffixed *-dependencies or *-recommended which both use Depends: and installing them using --no-install-recommends appeared to be the only solution.

Otherwise it would install packages such as virtuoso, soprano and vlc, which are not useful in context of Whonix-Gateway ™.

The Recommends: and Suggests: field is still being used but this is mostly useful for one package advertising related packages users using apt-cache show package-name and Packages for Debian Hosts.

Files in Home Folder[edit]

/home is for users. Not for distribution contributors.
Leads to a dpkg interactive conflict resolution dialog when package file is updated, in case file gets modified by the user or a program in the home folder, which is a usability issue, which we try to avoid.
serious lintian error dir-or-file-in-home ^[archive].
- Makes the package unfit for inclusion into packages.debian.org (very long term goal) (or other package repositories).
- Looks amateurish in the eyes of Debian packagers.
For which user? User user only? Inconsistent for multi user use cases. Hard to combine with future Multiple Boot Modes for Better Security - an Implementation of Untrusted Root with user, user secureadmin and user superadmin.
Doesn't work / inconsistent in Qubes ^[archive] TemplateBasedVMs. Since packages are usually upgraded in TemplateVMs, the change never propagates to the home folder of the TemplateBasedVM since it has an independently persistent home folder.
- Special code would be required to handle these cases. Such as a script that runs after boot but in TemplateBasedVMs that are not DispVM-Templates only. Example:
  - https://github.com/Whonix/tb-updater/blob/master/lib/systemd/system/tb-updater-first-boot.service ^[archive]
  - https://github.com/Whonix/tb-updater/blob/master/usr/lib/tb-updater/first-boot-home-population ^[archive]
  - More code to carry around, understand interactions, bugfix, maintain, explain, audit.
In most cases there are more suitable mechanisms to reach the implementation goal than writing into the user's home folder.
- If not, the lack of such mechanisms should be discussed with / requested from upstream.

Files in /etc/skel[edit]

Files in /etc/skel are not as bad as files in /home folder.
- Works for any user.
Inconsistencies. Not deployed through /etc/skel mechanism if file is added to a package after a user account was created. I.e. users who upgraded will miss that file.
- Needs special code to handle such cases.
If the file from /etc/skel is in the user's home folder, it's hard to update it. Updating the file in /etc/skel won't effect the user's version of the file in the user's home folder.
- Needs special code to handle such cases.

Modifying Default Configuration of Third Party Packages[edit]

Taking systemd as an example. Suppose /lib/systemd/system/systemd-random-seed.service modifications are desired.

File /lib/systemd/system/systemd-random-seed.service is owned by a third party package systemd.

dpkg -S /lib/systemd/system/systemd-random-seed.service

dpkg -S /lib/systemd/system/systemd-random-seed.service

systemd: /lib/systemd/system/systemd-random-seed.service

Editing /lib/systemd/system/systemd-random-seed.service.
- Is the worst (changes get lost on systemd package gets upgraded) (there is a solution using dpkg-divert encapsulated in a more sane by using config-package-dev displace and we use it in Whonix ™ source code where it could not be avoided but if avoidable it is best avoided if possible somehow).
Shipping /etc/systemd/system/systemd-random-seed.service
- would be better but still not great (this is for local administrator, not linux distribution)
/lib/systemd/system/systemd-random-seed.service.d folder and a file such as /lib/systemd/system/systemd-random-seed.service.d/30_something.conf
- is an ideal solution for linux distributions such as Whonix since it does not takeover files by other packages and does not take away something from the local system administrator or user.

config-package-dev[edit]

Debian package xfce4-session owns file /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml. Therefore package whonix-xfce-desktop-config cannot directly overwrite it.

Preparing to unpack .../whonix-xfce-desktop-config_1.4-1_all.deb ...
Unpacking whonix-xfce-desktop-config (3:1.4-1) ...
dpkg: error processing archive /mnt/initialdeb/pool/main/w/whonix-xfce-desktop-config/whonix-xfce-desktop-config_1.4-1_all.deb (--unpack):
 trying to overwrite '\''/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml'\'', which is also in package xfce4-session 4.12.1-6
Errors were encountered while processing:
 /mnt/initialdeb/pool/main/w/whonix-xfce-desktop-config/whonix-xfce-desktop-config_1.4-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)       '
+ apt_get_exit_code=100

config-package-dev can help with such situations.

Examples on how to use config-package-dev displace:

Ideally avoided as per above.

https://debathena.mit.edu/config-packages/ ^[archive]