Discussion :

[Access_to_folder]

Bonjour à tous,

Je me permets de soumettre à la communauté une réflexion concernant la gestion des installations logicielles sur des systèmes non connectés à Internet, en particulier dans les environnements GNU/Linux et FreeBSD. Cette problématique, bien que connue, reste souvent reléguée au second plan, alors qu’elle constitue un frein réel dans certains contextes professionnels, pédagogiques ou sécuritaires.

Constat : une complexité persistante hors ligne

Les systèmes GNU/Linux et FreeBSD reposent sur des gestionnaires de paquets puissants (APT, DNF, Pacman, pkg, etc.), conçus pour fonctionner de manière optimale avec un accès réseau. Or, dès lors que l’on se trouve dans un environnement déconnecté (air-gapped, réseau restreint, ou simple machine isolée), l’installation de logiciels devient rapidement laborieuse :
- Résolution manuelle des dépendances (parfois en cascade).
- Nécessité de scripts ou d’outils tiers (apt-offline, synaptic, pkg fetch…).
- Transfert manuel des paquets et gestion des versions compatibles.

Cette situation contraste fortement avec l’approche adoptée par Apple sur macOS, pourtant basé sur FreeBSD, qui propose depuis longtemps des archives `.dmg` ou `.pkg` auto-suffisantes, contenant l’ensemble des dépendances nécessaires à une installation hors ligne fluide et prévisible.

Ce n'est pas une impossibilité technique

Il est important de souligner que cette différence ne relève pas d’une contrainte technique insurmontable. Le socle BSD de macOS démontre qu’il est tout à fait possible de concevoir un format d’archive logicielle intégrant les dépendances, sans renier les principes d’un système Unix-like. Il s’agit avant tout d’un choix d’ergonomie, de distribution et d’intégration.

Vers une évolution concrète ?

Je souhaiterais soumettre à discussion l’idée suivante :

- Définir un format d’archive logicielle standardisé (par exemple `.pkgbox`, `.txz-bundle`, etc.) :
- Contenant le binaire, ses dépendances, et un script d’installation.
- Générable via un outil CLI ou GUI à partir d’un système connecté.
- Intégrer cette fonctionnalité dans les gestionnaires de paquets existants (via une option `--bundle` ou `--offline-export`).
- Permettre la création de ces bundles à partir des dépôts officiels ou de miroirs locaux.

Cas d’usage

- Déploiement dans des environnements sécurisés ou industriels sans accès Internet.
- Installations pédagogiques (ex. : salles de TP, Raspberry Pi en milieu scolaire).
- Archivage reproductible d’un environnement logiciel donné.


Une opportunité pour l’adoption grand public
Au-delà des bénéfices techniques et professionnels, une telle évolution pourrait également avoir un impact significatif sur l’adoption de GNU/Linux et FreeBSD en tant que systèmes d’exploitation de bureau. En simplifiant l’installation hors ligne — notamment pour les utilisateurs non techniciens — on réduirait une barrière d’entrée souvent décisive. Offrir des mécanismes d’installation plus intuitifs, comparables aux .dmg de macOS ou aux .exe de Windows, contribuerait à rendre ces systèmes plus accessibles, notamment dans les contextes éducatifs, associatifs ou domestiques.
En somme, il s’agirait d’un pas vers une meilleure ergonomie sans renier les principes d’ouverture, de modularité et de transparence qui font la richesse de nos systèmes.

[LittleWhite]

Bonjour,

Depuis quelques années, il y a pourtant des formats de logiciels qui sont indépendants (qui ne nécessite pas de dépendances) : les AppImage ou les Snap.
De plus, si vous utilisez un CD d'installation d'Ubuntu ou de Debian et que l'installation se fait sans Internet, alors une des sources des paquets configurés par défaut dans apt et le CD-Rom en lui même. D'ailleurs, je me rappelle avoir trois DVD d'Ubuntu 8.04 (acheté dans un bureau de presse ), ayant ainsi un "grand nombre" de paquet à disposition, sans pour autant avoir Internet...
Par conséquent, je considère (peut être à tort) le fonctionnement de apt hors ligne possible. apt-offline semble être conçu pour télécharger le logiciel et les dépendances afin d'en faire une installation hors ligne, ce qui me paraît logique. Vous prenez les paquets et leur dépendance (sur une clé USB) et vous les mettez sur la machine sans Internet. Bien sûr, je conseille d'utiliser apt-offline depuis une machine virtuelle qui serait une copie conforme de la machine sur laquelle installer le logiciel.

[Escapetiger]

Bonjour,

Il semble qu'il existe au moins une distribution Debian qui répond à tout ou partie de ces questions (non testée personnellement) :

https://www.debian.org/CD/http-ftp/

Merci à N_Bah ici

Distribution workstation 64 bits offline

[fred1599]

Hello,

Je pense que l'outil d'empaquetage guix pack est ce qui se rapproche le plus d'une proposition .pkgbox.

Elle est générée à partir du gestionnaire de paquets système, contient le binaire et toutes ses dépendances, et peut être rendue facilement exécutable. Elle est plus puissante car elle n'embarque pas seulement les dépendances, mais la clôture complète et reproductible de celles-ci, et peut même être utilisée pour la compilation croisée. Pour les cas d'usage les plus exigeants comme l'archivage et la recherche reproductible, le problème a déjà été résolu à un niveau fondamentalement plus profond par les gestionnaires de paquets fonctionnels.

https://guix.gnu.org/en/blog/2017/cr...ith-guix-pack/

[Access_to_folder]

De plus, si vous utilisez un CD d'installation d'Ubuntu ou de Debian et que l'installation se fait sans Internet, alors une des sources des paquets configurés par défaut dans apt et le CD-Rom en lui même.

Oui, tout comme la SUSE AVEC yAST permet d'avoir un dépôt local sur CD. Tout comme vous pouvez monter un dépot local sur une machine, ce qui est néanmoins fastidieux.

il y a pourtant des formats de logiciels qui sont indépendants (qui ne nécessite pas de dépendances) : les AppImage ou les Snap.

Mais… ils ne sont pas universels, sauf erreur de ma part :
• Pas standardisés au niveau du système : chaque format dépend d’un runtime ou d’un daemon spécifique
• Pas toujours préinstallés : sur FreeBSD, AppImage peut fonctionner, mais Snap et Flatpak nécessitent des adaptations.
• Pas intégrés aux gestionnaires de paquets classiques : APT, DNF, pkg, etc. ne les gèrent pas nativement.
• Pas toujours adaptés aux environnements professionnels ou sécurisés : sandboxing, dépendances binaires non vérifiables…

Je suis bien d'accord pour la facilité de Appimage, mais cela n'installe pas tel une installation ordinaire : fichiers répartis dans /usr, /etc, etc. mais reste un fichier unique.

Les formats AppImage, Flatpak et Snap restent minoritaires par rapport aux paquets natifs (.deb, .rpm, etc.), et peu de logiciels proposent systématiquement une version autonome dans ces formats ; rarement proposé en parallèle des formats natifs.


Comparaison avec les formats natifs (Généré par IA, car je n'ai pas trouvé aisément les chiffres )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
| Format       | Nombre approximatif d’applications | Intégration dans les distributions | Usage hors ligne | Popularité |
|--------------|-------------------------------------|------------------------------------|------------------|------------|
| `.deb/.rpm`  | > 50 000 (selon distribution)       | Native, complet                    | Oui              | Très élevé |
| **Flatpak**  | ~2 000 (Flathub)                    | Partiel                            | Oui              | Moyen      |
| **Snap**     | ~6 000 (Snap Store)                 | Fort sur Ubuntu                    | Oui              | Moyen      |
| **AppImage** | ~1 500 (AppImageHub)                | Faible                             | Oui              | Faible     |