Actions

Dev/About Debian Packaging

< Dev

Recommends vs Depends[edit]

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

debian/control: There are separate meta packages 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-get with --install-recommends, which is apt-get's default option, because that would also install packages recommend by any dependency we install.

On the other hand, if we installed using apt-get --no-install-recommends, the packages Whonix's 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 Whonix Packages for Debian Hosts.

See also Whonix_Debian_Packages#Technical_Stuff.

Files in Home Folder[edit]

  • /home is for users. Not for distribution maintainers.
  • Leads to a Whonix_Configuration_Files#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.
    • Makes the package unfit for inclusion into packages.debian.org (very long term goal) (or other distribution archives).
    • Looks amateurish in the eyes of Debian packagers.
  • For which user? User user only? Inconsistent for multi user use cases.
  • Doesn't work / inconsistent in Qubes 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.
  • 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.

Random News:

Are you proficient with iptables? Want to contribute? Check out possible improvements to iptables. Please come and introduce yourself in the development forum.


https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.

Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)