Parameterized Packages for GNU Guix

Sarthak Shah — 2023-06-09

Hello Guix!

I'm Sarthak and I'll be working on implementing Parameterized Packages for GNU Guix as a Google Summer of Code intern under the guidance of Pjotr Prins and Gábor Boskovits.

What are Parameterized Packages?

One of the many advantages of free software is the availability of compile-time options for almost all packages. Thanks to its dedication to building all packages from source, Guix is one of the few GNU/Linux distributions that can take advantage of these compile-time features; in fact, many advanced users such as those using Guix on High-Performance Computing Systems and new ISAs like RISC-V have already been doing this by utilizing a feature known as Package Transformations.

Parameterized Packages are a new type of package transformations that will be able to tweak an even wider array of compile-time options, such as removing unused dependencies or building a package with support for just a specific locale. These will have a wide variety of applications, ranging from High-Performance Computing to Embedded Systems and could also help tackle a few of Guix's issues like large binary sizes and dense dependency graphs.

What would these look like?

The syntax for parameterized packages is still under heavy deliberation, however the final syntax will have the following features:

• Maintainers will be able to specify what combinations of parameters a package supports, along with a default configuration of parameters for a given package.
• Users will be able to pass parameters they want enabled or disabled through --with-parameters which will then get validated against the valid combinations specified by maintainers before being run
• For a given package and a given set of parameters, only those in the package's parameter specification will be used
• Users will be able to specify a global parameter transform that will apply to all packages. Packages will be built with the default configuration if the global transform creates an invalid configuration.

Potential Problems with Parameterization

Combinatorial Explosion of Variants

One of the biggest and most obvious issues with parameters is the combinatorial explosion of package variants they will create. One way to address this is to use tools to calculate and regulate allowed complexity; one such tool could be a function that takes a parameter combination specification and returns the number of variants it could create.

Increase in Maintenance Required

Another concern is that this will lead to an increase in the workload of maintainers, who have been generously volunteering their time and have a lot of work as is. Hence, we will be treating parameters the same way we have been treating other package transformations- they are not expected to be stable, and should be used at the user's discretion.

Availability of Substitutes for Variants

Lastly, parameterization could lead to an exponential increase in the number of substitutes build farms will have to create, and thus as such there are only plans on building substitutes for default and very popular parameter combinations.

Other topics under discussion

Some of the other points of discussion with respect to parameters are

• Scope: Parameterization has a very wide and overarching scope, and it would be useful to have guidelines in place for when a particular property should be considered for parameterization
• Syntax: There are many proposed syntax designs for parameterization, and more are welcome! The final syntax will most probably be an amalgamation of the best parts of all proposed designs.
• Substitutes: There is a lot of discussion on exactly what parameter combinations should be considered for substitutes; while it is obvious that it won't be possible to build all combinations, some important combinations can and should be considered for having substitutes built. We could perhaps have a separate category of parameter combinations that would both receive substitutes and support, and make these combinations discoverable through the UI. Another suggestion is to have user-run channels for specific build combinations, like for example there could be a RISC-V specific channel supplying substitutes for the users running RISC-V.

If you would like to join the discussion, check out this mailing list discussion about this project, and also have a look at the original thread about parameterization.

Conclusion

Parameters hold the potential to greatly increase Guix's flexibility, but will also lead to greater complexity. In my opinion, Guix is uniquely positioned to take full advantage of the customizability provided by compile-time options while also enjoying relative stability thanks to its transactional nature.

About Me

I'm a student studying Mathematics and ECE at BITS Pilani, and I love computers and free software. I am the president of my university's equivalent of a Free Software Advocacy Group, and I am also one of the system administrators for my university's High-Performance Computing System. As an advocate for free software and a Lisp user, I naturally fell in love with GNU Guix when I discovered it. I have also used Gentoo for some time in the past, which motivated me to try and bring something similar to USE flags to Guix. You can find my blog at blog.lispy.tech, where I will be frequently posting updates about the project.

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, AArch64 and POWER9 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.