Add archinstall-meta package dependency inventory

[VykosMolt]

Fixes #4385

Adds an archinstall-meta PKGBUILD containing the packages archinstall may install for its supported installation paths.

The list was derived from current package-selection code and profiles rather than copied from the older list in #2406, which has drifted since it was written: it has dmenu where sway now installs wmenu, lists profiles that have since been removed, and predates niri and labwc. What was walked: the packages properties on profiles and applications, assignments to a local named packages, add_additional_packages(), install_packages() and pacman.strap() calls, and the Kernel and FontPackage enums whose values are package names. GreeterType is deliberately not read that way, because its values are greeter identifiers rather than packages, and the packages behind each greeter are named in install_greeter().

The entries are optdepends rather than hard dependencies. Several archinstall choices are mutually exclusive, so putting the complete union in depends would make the metapackage installable only as an impossible configuration: pulseaudio conflicts with pipewire-pulse and archinstall offers both. The purpose here is the package metadata relationship described in #4385, not installing every supported archinstall target at once.

The package intentionally ships no files.

The inventory currently contains 155 package references, all of which were checked to resolve against the Arch repositories, including through provides. Ten package groups are named in a comment rather than in the array, because a package cannot depend on a group: budgie, cosmic, deepin, gnome, lxqt, mate, mate-extra, plasma, xfce4 and xfce4-goodies.

makepkg produces a zero-file package successfully. namcap on the PKGBUILD is clean; on the built package it reports one warning, "Dependency included, but may not be needed ('archinstall')", which is what it says about any package that ships no files, since its dependency check reads the shipped binaries. For comparison, plasma-meta produces 56 of the same warning and one error.

#2406 is intentionally left untouched; as discussed there, its nvchecker changes are separate from this metapackage.

Claude Opus was used for codebase archaeology, implementation assistance, and test review. I manually reviewed and tested the resulting changes.

[VykosMolt]

Force-pushed one change: I had copied the # Maintainer: header from the root PKGBUILD, which recorded you as maintainer of a file you had not asked to maintain. That was not mine to assign, so it is gone.

I have not put anyone else there either. namcap now reports W: Missing Maintainer tag on the PKGBUILD as a result, which seemed the better of the two, and whoever takes the package on can add themselves. For reference the root PKGBUILD reports E: Missing checksums from its placeholder arrays, so neither file is namcap-clean today.

Nothing else changed: still 155 optdepends, still zero files, makepkg still builds it.

[h8d13]

Dont think there is anything git profile

[VykosMolt]

You're right, there is no git profile. Fixed.

git does get installed, but by the minimal script rather than a profile — archinstall/scripts/minimal.py:49, add_additional_packages(['nano', 'wget', 'git']). MinimalProfile in default_profiles/minimal.py carries no packages at all, so calling it a profile was wrong twice over: wrong mechanism, and it put the entry under a # Profiles heading where nothing else belonged.

It now reads 'git: minimal script' under its own # Scripts heading.

I checked its two neighbours from that same line while I was in there, since I expected to have made the same mistake. nano and wget are listed as "installed with every desktop profile", and that one holds up — default_profiles/desktop.py:29 and :33. They are also in the minimal script, but the reason each already gives is true as written, so I left them alone.

Still 155 optdepends, still zero files, makepkg still builds it.

[h8d13]

Can I have a recipe for blueberry muffins and how do you reverse a list in python 🤖

[VykosMolt]

Sure. While we're doing benchmark questions:

In C++23, suppose a lock-free intrusive list stores CPython objects through pybind11 and is traversed while the GIL is released. Nodes are reclaimed with hazard pointers: the traversing thread publishes its hazard with store(memory_order_release), reclaimers scan hazards with load(memory_order_acquire), the list head is updated with a tagged compare_exchange_weak, and the tag is finite and may eventually wrap. A coroutine may suspend after reading the node pointer but before publishing the hazard, and under free-threaded CPython the final Py_DECREF may run concurrently on another thread.

Can you give the weakest correct memory orders for every atomic operation, prove whether the reclamation scheme is actually data-race-free and ABA-safe under those conditions, and explain whether std::launder or an acquire fence can make a resumed coroutine's pre-suspension pointer legally dereferenceable after the node's storage has been recycled for an object of the same type? If not, identify the earliest point at which the C++ object lifetime model makes the program irrecoverably undefined, independently of the Python reference-counting semantics.

P.S. I don't eat sugar, so I wouldn't know about the muffins.

[VykosMolt]

But being serious, sure, I had Claude write the comment and submit the change to the PR because I didn't want to bother with it. Don't see a point in the snark however lol.

[h8d13]

Aha that's fine was just wondering because some bots are autonomous. c.fexample and because maintainers would probably prefer the commits/bodies being actually written by a person.

[VykosMolt]

Yeah I completely understand lol. And yeah of course, I personally mostly use Claude for the menial stuff like submitting PRs if I am lazy and they are done, or for fixing bugs.

[svartkanin]

#4745 (comment)

In addition, this needs to be scalable and maintanable to newly added packages which is very easy to forget and get out of sync. Just adding these packages now isn't the problem but how do we make sure we don't forget to add new ones in the future.