Dev/Metapackages

From Kicksecure
< Dev
Jump to navigation Jump to search

Development Notes / Design Documentation about Kicksecure Metapackages

Goals[edit]

  • Categorize packages such that Kicksecure can be built for a number of different environments (physical hardware, KVM, VirtualBox, Qubes) by installing one or more metapackages.
  • Allow Distribution_Morphing.

Design Update Ideas for Trixie[edit]

The current naming scheme for metapackages seems rather inconsistent. There's no clear rules to the naming, and while there are some conventions, they aren't followed reliably. Plotting a graph of the dependency tree using graphviz resulted in a very messy graph (sometimes it was difficult or impossible to figure out which lines went where). To make things easier to understand and maintain over time, a system somewhat like the following might work:

  • Each metapackage has a name structured somewhat like a directory path. Each component of the name is called a 'node'. Each node describes which category or subcategory the package falls under. The node separator character is the dash (-). Note that some nodes contain dashes in their names, so you cannot split a package name using dashes as the delimiter and get a list of nodes.
  • Each node is either independent, shared, or partially shared. An independent node is one that does not enforce any dependency rules on the metapackage that node is a part of. A shared node is one that requires that any package containing a sibling node must depend on the corresponding package from the shared node. A partially shared node behaves like a shared node, but only enforces a dependency with certain sibling nodes. Examples of this are shown below.
  • Not every single possible combination of nodes is expected to exist. If a package is mandated as "to be depended on" based on the below rules, but it doesn't actually exist, it may be ignored.
  • Node 1: OS
    • kicksecure - Independent node. For Kicksecure-specific packages.
    • whonix-gateway - Independent node. For Whonix Gateway specific packages.
    • whonix-workstation - Independent node. For Whonix Workstation specific packages.
    • whonix - Partially shared node, connected to whonix-gateway and whonix-workstation. For Whonix packages shared between all Whonix variants but not with Kicksecure.
    • dist - Shared node. For packages that are shared between Kicksecure and both Whonix variants.
  • Node 2: Hardware platform
    • general - Shared node. For packages that provide functionality that should be present regardless of the hardware platform.
    • nonqubes - Independent node. For packages that should be installed only when not running in a Qubes OS template or AppVM.
    • qubes - Independent node. For packages that should be installed when the system is running as a Qubes OS template or AppVM.
    • nonvm - Independent node. For packages that should be installed when the system is not running under a VM. TODO: rename this baremetal?
    • vm - Independent node. For packages that should be installed when the system is running under a VM.
  • Node 3: Persona
    • server - Independent node. For packages that are specific to a server use case.
    • cli - Shared node. For packages that should be present on all Kicksecure systems. A system consisting only of CLI packages may be useful as a minimal text-only machine.
    • gui - Independent node. For packages that should be present on GUI-enabled systems.
  • Node 3a: GUI Environment
    • NOTE! Only present when the persona node is 'gui'!
    • xfce - Independent node. For packages specific to an XFCE desktop.
    • lxqt - Independent node. For packages specific to an LXQt desktop.
    • etc... (fill in the same for gnome, kde, whatever)
    • all - Shared node. For packages that should be present on all GUI systems.
  • Node 4: Priority
    • essential - Shared node. For packages that absolutely must be present for the particular OS, hardware platform, persona, and GUI environment (if applicable) to be considered complete.
    • recommended - Independent node. For packages that should usually be present on this specific OS/hardware/persona/GUI environment combination.
  • Examples:
    • kicksecure-general-server-essential: Packages which MUST be present on all Kicksecure servers.
      • Shared nodes involved are dist for node 1 and cli for node 3, thus this package must depend on dist-general-server-essential, kicksecure-general-cli-essential, and dist-general-cli-essential.
    • whonix-workstation-nonqubes-cli-recommended: Packages which are recommended for all Whonix Workstation systems that are not running under Qubes OS.
      • Shared nodes involved are whonix on node 1, dist for node 1, general for node 2, and essential for node 4, thus this package must depend on whonix-workstation-nonqubes-cli-essential, whonix-workstation-general-cli-recommended, whonix-workstation-general-cli-essential, whonix-nonqubes-cli-recommended, whonix-nonqubes-cli-essential, whonix-general-cli-recommended, whonix-general-cli-essential, dist-nonqubes-cli-recommended, dist-nonqubes-cli-essential, dist-general-cli-recommended, and dist-general-cli-essential.
  • Observations:
    • Every single thing will end up depending on dist-general-cli-essential.
    • Everything recommended will end up depending on dist-general-cli-recommended.
    • You can install a full Kicksecure GUI system on your physical machine by installing kicksecure-nonvm-gui-xfce-recommended.
    • Dummy packages aren't described in the above, they're pretty straightforward though.
  • Questions
    • Is this whole thing overkill? I feel like it will make the system easier to maintain over time, but it's a radical departure from how things work now and would probably mandate full reinstalls or a substantial amount of package fiddling on upgrade in order to transition from the old way to this way. Definitely if we want to go with this scheme, it will have to wait until Trixie because it will be very difficult (probably impossible) to switch to this in a totally safe way during the Bookworm release. If we wait until Trixie to do it though we can just say that upgrades are unsupported, you have to reinstall.
    • Should there be another node type under "Priority", for packages that are suggested but strictly optional?
    • Is there any way that we can do --no-install-recommends for packages in general but then do install direct recommends of our packages? Right now we're duplicating Debian's Depends/Recommends/Suggests system to some degree, and this proposed scheme does the same thing but potentially even more "strongly". It would be great if we could just have a kicksecure-nonvm-gui-xfce package that had essential, recommended, and supported packages broken up as Depends/Recommends/Suggests.

Auditing Tools[edit]

Footnotes[edit]

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Dev/Metapackages&oldid=87868"