Le sodalite est un OS de bureau immuable construit avec RPM-Ostree et sur le dessus de Fedora - similaire à Fedora Silverblue - en utilisant le bureau Pantheon, en collant étroitement à l'éthique et au flux de travail perpétré par élémentaire.
Oui.
Malgré une histoire de validation très active, le sodalite est assez autonome de nos jours - principalement grâce aux gens formidables de Fyra Labs - et donc le référentiel passera des mois sans aucune activité. Cela ne signifie pas que le projet est abandonné, d'autant plus que son développeur l'utilise comme le système d'exploitation principal. Quelle que soit l'activité du référentiel, les mises à jour sont construites deux fois par semaine à partir du référentiel: les journaux sont disponibles dans les actions.
PSST! Nous sommes aussi sur Telegram. Bien que vous soyez libre d'utiliser des discussions, la majorité de la discussion relative à ce projet se produira sur Telegram.
Comme RPM-Ostree est une technologie en constante évolution et que les installations ISO sont actuellement une faible priorité, les ISO ne sont actuellement pas disponibles . Un système d'exploitation basé sur RPM-Ostree existant, comme Fedora Silverblue, est requis: ce système d'exploitation sera utilisé pour "réprimander" de la sodalite.
sudo ostree remote add --if-not-exists sodalite https://ostree.sodalite.rocks --no-gpg-verifysudo ostree pull sodalite:sodalite/current/x86_64/desktop *sudo rpm-ostree rebase sodalite:sodalite/current/x86_64/desktop* Il y a plusieurs branches disponibles; Voir les branches .
Plusieurs branches (ou images) de la sodalite coexistent et sont développées côte à côte; Ceux-ci se distinguent par leur référence - comme toute autre distribution RPM-Ostree - où sodalite/<version>/<arch>/<edition> :
<version> | <arch> | <edition> | Libérer | Base | Statut |
|---|---|---|---|---|---|
current | x86_64 | desktop | 6 kutai | Fedora 39 |
<version> | <arch> | <edition> | Libérer | Base | Statut |
|---|---|---|---|---|---|
long-6 | x86_64 | desktop | 6 kutai (long) | Fedora 39 |
Contrairement au courant (
current), ces succursales ne mettent pas à jour vers la version majeure actuelle: les mises à jour s'arrêteront le même jour que la version Fedora de base . Utilisez-les uniquement si nécessaire (c'est-à-dire les conducteurs problématiques nécessitant certaines versions, systèmes critiques, etc.)
<version> | <arch> | <edition> | Libérer | Base | Statut |
|---|---|---|---|---|---|
next | x86_64 | desktop | 6 Kutai (Suivant) | Fedora 39 | |
next | x86_64 | desktop-gnome | 7.0rc3 Gnome (Suivant) | Fedora 40 |
Les premières versions des versions à venir. Instable. Voici des dragons. Abandonnez tout espoir. Vous connaissez l'exercice.
Cela peut parfois être à la même version que le courant (
current), mais sachez que vous serez heurté à une version à venir sans avertissement si / quand il est libéré dans cette branche.
(Faire)
L'exécution d'une mise à jour système peut être effectuée par soit:
sudo rpm-ostree upgrade dans un shellRedémarrez après la fin de l'une ou l'autre méthode. Vous pouvez vérifier la version installée en ouvrant les paramètres du système et en accédant au système ➔ Système d'exploitation : la version décroche le mot "sodalite"
Si quelque chose se casse, vous pouvez retourner en exécutant sudo rpm-ostree rollback à un terminal. N'oubliez pas de créer également un nouveau problème le cas échéant!
Les mises à jour sont construites sur le serveur de construction commençant à 4:00 GMT / ± 0 (22:00 CST / -6) tous les mercredis et samedis .
Si vous avez choisi d'utiliser une branche "à long terme" (voir les branches ci-dessus), vous devrez récompenser chaque fois que la version Sodalite atteint la fin de vie. Cela peut être fait avec sudo rpm-ostree rebase sodalite:sodalite/<version>/<arch>/<edition> , où <version> est la version que vous souhaitez réprimander et d'autres valeurs sont vos valeurs actuelles.
Il est essentiel que vous effectuiez ce processus, car les mises à jour arrêtent le jour où la version de base atteint la fin de vie (en même temps que la version Fedora Linux de base) et vous serez laissé sans mises à jour des composants système vitaux.
--container / -c )Courir dans un conteneur est le moyen préféré de construire du sodalite
--ex-use-docker . Courir dans Docker est entièrement non testé et expérimental!git lfs : Une aide à la sortie d'aide est installée si vous êtes installé Si vous n'avez pas de podman, ou si vous avez des problèmes de course dans un conteneur, vous pouvez essayer de courir sur l'hôte lui-même
dnf install rpm-ostreegit lfs : Une aide à la sortie d'aide est installée si vous êtes installé sudosudo ./build.sh : le script demandera la permission quand il en aura besoinsudogit clone https://github.com/sodaliterocks/sodalite.git
cd sodalite
git submodule sync
git submodule update --init --recursiveLors de la mise à jour à l'avenir, n'oubliez pas de mettre à jour les sous-modules avec:
git submodule update --recursive N'utilisez pas git submodule foreach git pull : cette mise à jour aveuglément met à jour tous les sous-modules de leur dernière version, et non le commit que ce repo parent a vérifié. Ceci est important pour certains sous-modules qui sont vérifiés à des balises / valids spécifiques (tels que ./lib/sodaliterocks.firefox ).
Les sous-modules ./lib/workstation-ostree-config_f* - servant de base de sodalite pour ses différentes versions basées sur Fedora - sont supprimées de temps en temps, alors assurez-vous de les supprimer en conséquence. Par exemple, lorsque Fedora 36 atteint EOL, ./lib/workstation-ostree-config_f36 sera supprimé peu de temps après. Vous pouvez utiliser git clean -i pour faire le travail pour vous.
Un sous-module LFS est situé sur ./lfs . Il est important de noter que ce n'est pas hébergé sur GitHub, mais Zio Git - un serveur que nous contrôlons - car les allocations LFS de GitHub sont serrées (seulement la bande passante et le stockage 1Gib).
Tout problème concernant le LFS doit être soumis à Sodaliterocks / Sodalite sur GitHub. Actuellement, comme Zio Git ne permet pas les inscriptions arbitraires, PRS ne peut pas être directement soumis.
À moins que le monde ne favorise collectivement Gitlab, ou toute autre chose, Sodalite restera sur Github car cela facilite la vie de chacun. Microsoft n'est qu'une autre entreprise; Ils ne vont pas vous blesser.
./build.sh [-t < edition > ] [-w < working-dir > ] Voir build.sh --help pour plus d'options.
Cela prendra généralement 10 à 15 minutes. Tu te souviens quand je t'ai dit de prendre une tasse de thé? Ou peut-être un froid?
<edition> (Facultatif) Édition / Variante de Sodalite (par défaut est custom )sodalite-<edition>.yaml répertoriés dans ./src/treefiles/ . Utilisez sodalite-<edition> , soit Just <edition> comme argument. Actuellement, il y a:desktop : bureau de panthéon standarddesktop-gnome : Bureau de gnome alternatif, destiné à d'éventuelles versions futurescustom : voir le point ci-dessoussodalite-custom.yaml est un bon endroit pour utiliser vos propres changements au lieu de modifier l'un des autres fichiers d'arbres<working-dir> (facultatif) répertoire pour la sortie de build (par défaut ./build ) Si vous avez Podman, vous pouvez construire entièrement du sodalite dans un conteneur: utilisez simplement -c / --container . C'est en fait comment les builds sont effectués sur le serveur de version! Cependant, cela ajoutera quelques minutes supplémentaires à terminer car le conteneur Fedora doit d'abord installer des packages.
Les échecs de construction sont inévitables sur les disques formatés en NTF, FAT ou tout autre système de fichiers qui ne prend pas en charge les autorisations de type UNIX, car build.sh définit les autorisations sur divers objets.
Sur WSL2, ne construisez pas sur les répertoires /mnt/<drive-letter> car ceux-ci seront formatés sous forme de NTFS ou de graisse. Au lieu de cela, exécutez la construction ailleurs sur la distribution Linux elle-même (comme $HOME ou /usr/local/src ).
build.sh La plupart des distros RPM-Ostree peuvent être construites simplement faire rpm-ostree compose , mais build.sh fourni avec Sodalite fait des étapes supplémentaires requises pour le script post-construction (qui échouera sans être exécuté). Il n'est donc pas recommandé de le faire de cette façon: tout problème de construction de la distribution de cette façon sera fermé et marqué comme invalide.
Build Content est situé sur ./build/ (ou tout ce que vous définissez <working-dir> ), qui peut être supprimé pour recommencer. Plus précisément, cela contient les fichiers / répertoires suivants (dont peuvent être supprimés individuellement à la place):
./build/repo/ - Référentiel d'ostree pour Sodalite./build/cache/ - Cache pour packages Fedora Sauf arrêté manuellement, build.sh se nettoie chaque fois qu'il sortira (sur le succès et l'échec). Il corrigera les autorisations (à votre utilisateur) pour le répertoire ./build/ , ainsi que la suppression des fichiers / répertoires suivants:
./src/sysroot/common/usr/lib/sodalite-buildinfo/var/tmp/rpm-ostree.*/build.sh(faire)
Le travail de ces beaux gens n'est plus inclus ou pertinent pour Sodalite, mais ils valent toujours un cri!
?? ??