On retombe sur le même problème : la compilation, et surtout la création de paquet, est spécifique à chaque distro. Les devs n'ont pas à gérer les différents systèmes de paquets.
Tout à fait, je me suis de plus mal exprimé. Je parlais bel et bien d'un format unique côté amont, binaire et transposable en paquets pour distributions. Mais je suis bien conscient que c'est au final utopique, les bibliothèques se présentant dans différentes versions selon la distribution, le numéro de version de la distribution, etc.
A mon avis, c'est plus qu'une difficulté, c'est pratiquement une impossibilité, on est dans l'impasse.
Par contre, si on accepte d'avoir côte à côte les deux mondes (paquets de la distro et applications tierces), ça doit pouvoir se faire : on a déjà LSB et des systèmes de gestion de dépendances. Manque la glue qui permettrait au mieux d'installer à la demande les libs requises depuis la distro, au pire d'installer des libs hors-distro venant avec l'application.
Même problème que sus-cité. Comme à peu près tous les choix dans le monde de l'informatique, celui des liaisons dynamiques aux bibliothèques comporte son lot de bons et mauvais côtés, c'est juste une histoire d'affinités avec les buts/idées du projet (ici c'est il me semble le partage en mémoire et la sécurité qui ont primé, me corriger au besoin si je dis des âneries).
Pour la glu, PackageKit propose d'installer wget ou vim si je tape la commande et que le programme n'est pas installé, apt-get/aptitude aussi je crois, donc effectivement ça doit être de l'ordre du possible. Là le problème du nommage des paquets de bibliothèques se pose et, plus complexe encore, le découpage en plusieurs binaires d'un jeu de sources ou non (libXX-core, libXX-dev, etc).
La glu serait donc propre à chaque distribution ? Une partie applicative standard et une partie "dictionnaire" différente par saveur de GNU/Linux (comme tente de le faire PackageKit en tant qu'emballage avec rpm / dpkg derrière en gros)
Après tout, l'arborescence /usr/local (ou /opt ) est historiquement là pour ça.
[^] # Re: Pour un app store GNU/Linux multi distro
Posté par Tom . En réponse à la dépêche Nouveau projet Debian CUT. Évalué à 1.
Tout à fait, je me suis de plus mal exprimé. Je parlais bel et bien d'un format unique côté amont, binaire et transposable en paquets pour distributions. Mais je suis bien conscient que c'est au final utopique, les bibliothèques se présentant dans différentes versions selon la distribution, le numéro de version de la distribution, etc.
Même problème que sus-cité. Comme à peu près tous les choix dans le monde de l'informatique, celui des liaisons dynamiques aux bibliothèques comporte son lot de bons et mauvais côtés, c'est juste une histoire d'affinités avec les buts/idées du projet (ici c'est il me semble le partage en mémoire et la sécurité qui ont primé, me corriger au besoin si je dis des âneries).
Pour la glu, PackageKit propose d'installer wget ou vim si je tape la commande et que le programme n'est pas installé, apt-get/aptitude aussi je crois, donc effectivement ça doit être de l'ordre du possible. Là le problème du nommage des paquets de bibliothèques se pose et, plus complexe encore, le découpage en plusieurs binaires d'un jeu de sources ou non (libXX-core, libXX-dev, etc).
La glu serait donc propre à chaque distribution ? Une partie applicative standard et une partie "dictionnaire" différente par saveur de GNU/Linux (comme tente de le faire PackageKit en tant qu'emballage avec rpm / dpkg derrière en gros)
La base est là, oui :-)