Seems like Arch Linux is going from strength to strength lately. Not only have Valve begun funding parts of the Linux distribution but now the Sovereign Tech Agency are as well.
Writing in an announcement on the Arch Linux development mailing list developer David Runge shared the news that Sovereign Tech Agency provided funding for developers Arne Christian Beer, Heiko Schäfer, Orhun Parmaksız and David Runge to work on ALPM part time over 15 months. Work started back in October, with it expected to continue through until the end of 2025.
The announcement mentions the funding supports multiple milestones for the project, which I've noted below:
Article taken from GamingOnLinux.com.Formal specifications for packaging data formats
The Arch Linux packaging ecosystem uses underspecified/undocumented file and metadata types, yet we need to be able to use them reliably in other contexts such as package creation, build and package repository management tooling.
Therefore this milestone involves developing versioned specifications for all low-level descriptor file and implementing Rust libraries based on them. These will be based on the existing ad-hoc reference implementations in
makepkg and pacman.Basic OpenPGP verification of artifacts
Signature verification in Arch Linux package management currently hinges on a stateful GnuPG keyring. This solution is brittle and has already caused various issues related to the Arch Linux keyring in the past.
To simplify signature verification - while at the same time enabling the use of a more diverse set of cryptographic technologies - a specification for the UAPI group will be written. An accompanying Rust library will be provided as a simple and stateless integration, not limited to use in Arch Linux.
Rust library for handling of individual packages
The structure of Arch Linux package files is currently not explicitly defined. This milestone focuses on providing a formal specification of what an ALPM-based package contains, how it is created and handled. A dedicated Rust library and tool will facilitate package creation, validation and installation.
These new Rust libraries will also expose a C API for possible integration into the C-based libalpm library.
Rust library for system package management
This milestone revolves around the use of the previously implemented components by providing a library for package download, validation, verification, installation and state handling similar to pacman's libalpm and will handle sets of individual packages on user systems.
A C-API will be provided for compatibility with libalpm-based applications.
One specific concern of this milestone is modernizing the OpenPGP integration.
Current package management tooling does not allow for scoping signature verifiers (e.g. OpenPGP certificates) for a specific purpose, such as "only packages" or "only repository metadata".
The new system will rely on a stateless approach such as the one to be proposed as specification to the UAPI group.
Distribution-agnostic OpenPGP stack for the verification of distribution artifacts
This milestone will focus on a set of foundational libraries, based on a UAPI specification from a previous milestone.
These libraries will add support for PGPKI (aka the “Web of Trust”) in the generic directory structure for OpenPGP certificates used for the verification of distribution artifacts.The libraries mentioned above will be integrated into the ALPM context to allow for example the full verification of packages and repository metadata.
A Rust-based solution will be provided as a modern alternative to the current
GnuPG-based approach.The outcome(s)
The ALPM project strives to build a modern, sustainable, maintainable and memory-safe framework for the Arch Linux packaging ecosystem. This framework will enable robust and predictable integration for all package
related tooling and libraries.The project goals are intentionally ambitious while being constrained to a relatively short period of time.
The work is organized so that real world benefits will happen early and often. Several infrastructure related projects have already reached out with a concrete interest to make use of libraries created in the first phase of the project.
The work will be done in the open, on the Arch Linux GitLab.
Everyone and anyone is welcome to join in and help out!
Quoting: no_information_hereQuoting: BrokattI had to google it. Apparently it's a german federal tech agency.
Yes, my first question was Sovereign to which country?
It would have been great to have more context:
https://en.wikipedia.org/wiki/Sovereign_Tech_Fund
Even their website avoids saying anything about Germany on most pages. Weird.
https://www.sovereign.tech/about
It's not immediately clear, but they don't exactly hide it either: https://www.sovereign.tech/faq.
ElectricPrism 21 hours ago
Quoting: CyborgZetaI wish them luck with that. Europe is extremely reliant on the US for defense. Especially Germany.
I would seem not everyone knows that USA heavily subsidizes the military costs of the world which allows them to use their own resources on health care and other things.
When I open up a Linux Blog to read the cool new things going on and I find US Politics in the comments and 100% emotional arguments it makes me feel like we're not a serious people -- and that we can't stay pragmatic and keep our criticisms on point. It's really discouraging to see.
Also, as it should be obvious too -- this hyper-emotionalism is no longer popular. If it were these arguments would have worked. But they are democratically considered unpopular.
Quoting: AdutchmanQuoting: no_information_hereQuoting: BrokattI had to google it. Apparently it's a german federal tech agency.
Yes, my first question was Sovereign to which country?
It would have been great to have more context:
https://en.wikipedia.org/wiki/Sovereign_Tech_Fund
Even their website avoids saying anything about Germany on most pages. Weird.
https://www.sovereign.tech/about
It's not immediately clear, but they don't exactly hide it either: https://www.sovereign.tech/faq.
No they don't hide hit. This page is a little bit better.
https://www.sovereign.tech/news/stf-part-of-new-sovereign-tech-agency
Quoting: no_information_hereEven their website avoids saying anything about Germany on most pages. Weird.It says it on every page:
QuoteSupported by
Federal Ministry for Economic Affairs and Climate Actions [with German "flag" & emblem]
on the basis of a decision by the German Bundestag
no_information_here 3 hours ago
Quoting: poiuzIt says it on every page:
QuoteSupported by
Federal Ministry for Economic Affairs and Climate Actions [with German "flag" & emblem]
on the basis of a decision by the German Bundestag
In a tiny graphic at the bottom of the page after scrolling down for 30 meters.
It reminds me of...
Quote“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
I do understand, every country thinks it is the centre of the universe. But some more so than others (the USA is the worst at this).
redneckdrow 3 hours ago
Quoting: ElectricPrismQuoting: WorMzyHopefully the user-facing packaging system remains as simple as it is currently. The PKGBUILD+makepkg way of creating packages is one of the main strengths of Arch.
Strongly Agree. PKGBUILD is amazing, I hope Arch doesn't do anything to complicate -- this is just like Prime Numbers and Exponents -- there is a optimal amount of complexity and a optimal amount of simplicity -- otherwise we would all program exclusively in assembly.
What I could get behind:
1. Optionally compile every package from source, and steal all the good ideas from Gentoo (Flags, Patches in etc)
2. LAN Mirrors. It would be nice if it were possible for Arch to ask LAN computers to also act as Mirrors -- then instead of downloading the same package 3-16 times it could be transferred locally similar to how Steam allows LAN to reduce bandwidth load and increase update speed on games.
3. Roll-back -- undoing the last software update in-case it has a problem or you just don't like it.
4. Set a target installation date where installed packages don't exceed X date and pull from the Arch Archive. (AFAIK this is presently possible to an extent)
5. More target architectures to compile against, ARM, RISCV
6. Warnings of new Arch News __prior__ to important updates which introduce breakage, eg: Pacman 6 => 7
I've run into some of the same problems, and found a few solutions, some clunkier than others:
You can already do #1 quite easily with the ABS via pkgctl (replaces the old asp tool) which uses the flags set in makepkg.conf.
#2 actually has an entire sub-section in Pacman tips and tricks listing several ideas. I didn't know that before today that was and added as a feature in pacman 6.1.0! There really should be more documentation on this kind of stuff.
You can also easily roll your system back using the AUR package downgrade which takes the guesswork out of using the ALA.
Several scripts and AUR helpers can do #6. For example, pikaur warns you by default; with a handy function to mark news as read before proceeding.
Patreon
PayPal
See more from me