Si tu as des paquets uniques pour x86 32/64bits (peut-être certains ARM si des notebook ARM sortent) tu couvres la vaste majorité des cas d'utilisations. Pour les autres architectures, tu laisse les sources et les gens font comme au bon vieux temps. Bref, le but c'est de rendre la vie plus simple aux utilisateurs de base.
Bon maintenant, je pense que c'est un format de paquets qui s'adresse plutôt aux logiciels "haut niveau", genre des trucs bâtits sur GTK et QT. Donc pas des logiciels qui utilisent directement des appels systèmes au noyau. Il me semble que Qt a une ABI compatible à l'intérieur d'une version majeure. Comme Qt fournit des abstractions pour tout un tas de choses (threads, mutex, réseau), ça permet peut-être de limiter le problème ?
[^] # Re: Pas d'accord...
Posté par Jux . En réponse au journal FatELF : binaires universels pour Linux. Évalué à 4.
Si tu as des paquets uniques pour x86 32/64bits (peut-être certains ARM si des notebook ARM sortent) tu couvres la vaste majorité des cas d'utilisations. Pour les autres architectures, tu laisse les sources et les gens font comme au bon vieux temps. Bref, le but c'est de rendre la vie plus simple aux utilisateurs de base.
Bon maintenant, je pense que c'est un format de paquets qui s'adresse plutôt aux logiciels "haut niveau", genre des trucs bâtits sur GTK et QT. Donc pas des logiciels qui utilisent directement des appels systèmes au noyau. Il me semble que Qt a une ABI compatible à l'intérieur d'une version majeure. Comme Qt fournit des abstractions pour tout un tas de choses (threads, mutex, réseau), ça permet peut-être de limiter le problème ?