archinstall
archinstall copied to clipboard
archlinux
Rework profile management
Reworking the current profile mangement
With the current version there are some major challenges. It is tightly coupled with archinstall.storage which means that any selection in the menu will modify the storage. This makes it very difficult to reset settings and/or override them without forgetting to cleanup the ones not set.
These major changes aim to make the profile handling more flexible and dynamic and give users the ability to programmatically generate profiles. Unfortunately, this is a breaking change and the old version of profile definitions will not work anymore.
@Torxed I've transferred over all existing profiles in the repository, but I tried my best to support an automatic transfer for profiles that have been defined by users. Unfortunately, that wasn't feasible without having to cover dozens of edge cases, so this will inevitably a breaking change :(
Related issues that should be fixed with this upgrade
- Fixes https://github.com/archlinux/archinstall/issues/234
- Fixes https://github.com/archlinux/archinstall/issues/395
- Fixes https://github.com/archlinux/archinstall/issues/601
- Fixes https://github.com/archlinux/archinstall/issues/606
- Fixes https://github.com/archlinux/archinstall/issues/611
- Fixes https://github.com/archlinux/archinstall/issues/612
- Fixes https://github.com/archlinux/archinstall/issues/740
- Fixes https://github.com/archlinux/archinstall/issues/999
- Fixes https://github.com/archlinux/archinstall/issues/1154
- Fixes https://github.com/archlinux/archinstall/issues/1175
New features
Profiles as classes
All profiles are now defined as a class. This allows that profiles can be inherited from each other, and therefore users can build profiles on top of other profiles. This will be essential when creating custom profiles :)
Programmatically create profiles
User will now have the ability to programmatically create profiles and inject them, as an example
class TestProfileV2(ProfileV2):
def __init__(self):
super().__init__('TestMe', ProfileType.CustomType)
@property
def packages(self) -> List[str]:
return ['my_fav_packages']
def install(self, install_session: 'Installer'):
install_session.add_additional_packages(self.packages())
handler = ProfileHandler()
handler.add_custom_profile(TestProfileV2())
This also has the major benefit that no separate files have to be create anymore for profiles.
Multiple profiles per file
Currently there's a single profile definition per file. One can now create profiles programmatically as shown above, or specify them
as in the current way in a separate file.
However, now one can also specify multiple profiles per file, since the actual class definitions will be recognized as the profile.
my_profiles.py
class ProfileOne(ProfileV2):
...
class ProfileTwo(ProfileV2):
...
Ability to install multiple desktop profiles
There is now the option to install multiple desktop profiles, similar to multiple servers that already exists
Display the packages to be installed on the desktop profiles
Select which greeter should be installed
Each desktop profile can define a default greeter. When selecting one or multiple desktop profiles, the user will get the option to chose which greeter should be installed with these profiles. As the default there will be a recommendation of the default greeter (if only one or if all have the same default).
Create custom profiles in the menu
In the profile menu, there's also the option to create custom profiles
They will also be exported as configuration settings. If they have been created and set to disabled, and another profile (e.g. Desktop) is set then they will still be exported, this case any definitions won't be lost.
New option in the Menu for "Back"
In some Menus it makes sense to display a visual "Back" option. This option will behave the same way as ESC essentially does but it is more intuitive.
Breaking changes
- Old profiles will not work anymore so they have to moved over to the new class format manually (all existing profiles in the repository have been moved over already)
Schema changes
The schema for the profile configuration has changed. Also the gfx driver configuration has been moved inside the profile configuration since it is never used as a standalone but only in combination with the respective profiles selected
"profile": {
"main": {
"description": "Main top level profile ",
"type": "string",
"enum": [
"desktop",
"minimal",
"server",
"xorg",
]
},
"details": {
"description": "Specific profile to be installed based on the 'main' selection; these profiles are present in profiles_v2/, use the name of a profile to install it (case insensitive)",
"type": "string",
"enum": [
"awesome",
"bspwm",
"budgie",
"cinnamon",
"cutefish",
"deepin",
"desktop",
"enlightenment",
"gnome",
"i3-wm",
"i3-gasp",
"kde",
"lxqt",
"mate",
"sway",
"xfce4",
"qtile",
"cockpit",
"docker",
"httpd",
"lighttpd",
"mariadb",
"nginx",
"postgresql",
"sshd",
"tomcat"
]
},
"custom": {
"description": "Specific profile definitions for custom setup profiles)",
"type": "array",
"items": {
"type": "object",
"properties": {
"packages": "string",
"services": "string",
"enabled": "boolean"
}
}
},
"gfx_driver": {
"description": "Graphics Drivers to install if a desktop profile is used, ignored otherwise.",
"type": "string",
"enum": [
"VMware / VirtualBox (open-source)",
"Intel (open-source)",
"AMD / ATI (open-source)",
"All open-source (default)",
"Nvidia (open kernel module for newer GPUs, Turing+)",
"Nvidia (open-source nouveau driver)",
"Nvidia (proprietary)"
]
}
},
This would be huge! Just the multi-select on it's own would be awesome hehe. I gotta test this thurrowly once I'm done releasing v2.5.1!
I'll let you know when it's ready ;)
@Torxed but as a question which I'm currently unsure about is how should we handle which greeter to install? Desktop profiles define lightdm and ssdm at the moment. Any suggestions here?
I'll let you know when it's ready ;)
@Torxed but as a question which I'm currently unsure about is how should we handle which greeter to install? Desktop profiles define lightdm and ssdm at the moment. Any suggestions here?
That's a good question.
It would be nice if the profiles defined a meta-class or something that we can use to determinate collisions, something along the lines of what you've already got, but make a Required structure as well as IncompatibleWith value that defines what absolutely doesn't work together.
In this case I would say it would be a collision and the two desktop profiles won't work side by side.
Or we'd need to defined a Decativate function/class of profiles so that we can undo any setups done, like disabling greeters. And then the user could select one or simply, we pick a default and pre-configure that - and the user will have to do some work to get the other DE up and running? :)
I like the idea of exclusion. Let me have a look at which profiles are absolutely incompatible, maybe we can list them separately and/or exclude them from multi select if it's only 1 or 2.
@Torxed I think this is ready for a review now I have tested it to a degree but it would be better to get someone new to jump on it :)
@Torxed now that the new release is out, any chance to start merging the open PRs :) ?
I'm full speed ahead! Feels like a classic but it's been a lot lately. But I'm in merge-mode and I'm planning on getting this in within an hour or so. Testing it now :)
Any reason why we removed /examples/?
I get that they moved into scripts, but the main reason for the /examples/ folder was to served as coding examples not just script entry-points. Could we move them back or would that be a horrific amount of change?
@Torxed the main reason I moved them under the scripts namespace was that they are used with the --script argument and therefore I think it makes sense having them located there.
I saw that the symlinked examples folder had to be explicitly handled for various operations (setup, pkgbuild...), and IDEs were quite confused with it (I'm entirely sure I could invest some time in setting it up properly)
I understand that they can also be seen as standalone examples, since they are essentially standalone. I'm happy to create the examples symlink again, but as an alternative I might also suggest to maybe just refer to the scripts as the examples in the Readme or create separate explicit examples since way the scripts are setup they are not covering some actual use cases :)
Tested it, seems to not like updating the arch keyring as it spits out an error.
@VexfulNiko interesting, would you mind sharing the steps and possibly error?
@Torxed any more thoughts on this PR otherwise or can we aim to get it into the next release 😀
@svartkanin Just downloaded the Arch ISO and ran the Arch install, and it created errors saying it couldn't update the arch keyring. I tried to ping to ensure I had internet, and I did.
This PR isn't even merged so I don't think it has anything to do with the problem you encountered
An testing Archiso was created with this pr request if you go into actions
Ahh I see, regardless I don't think it has anything to do with the changes in this PR.
Have you tried running pacman -Sy archlinux-keyring?
Ahh I see, regardless I don't think it has anything to do with the changes in this PR.
Have you tried running
pacman -Sy archlinux-keyring?
The latest archiso was built with this bug. For now doing rm -rf /etc/pacman.d/gnupg then pacman-keyring init pacman-keyring --populate archlinux fixes it. Also lsblk gives an error.
I am sorry but you fucked up the installer. It's not a shame to make a mistake but it's a shame to deny it. Please fix it.
@atillabirer How would this PR have "fucked up the installer" if the PR isn't even merged yet?
Has been merged into https://github.com/archlinux/archinstall/pull/1604 and will be added with it