On 10-05-24 10:13 AM, Michael Faille wrote: > Moi jai limpression que ubuntu est parfois victime de son succes. Les > gens aprecient ubuntu parce quun systeme vanille fonctionne bien. > > Cependant I'll est possible que le systeme vanille ne corespondent pas > au besoin de lutilisateur quand I'll utilise un logiciel non supporter > ex: les meilleurs jeux sous ubuntu, des versions particuliere de > logiciel souvent necessaire sur un ubuntu server lts quand une > version x est requise pour la correction dun bug ou lapport dun > feature important. --->Ex: asterisk 1.6, samba 3.4 (Pour dancienne > version de ubuntu) et quake 4. > Mhh.. je suis certain que c'est dans la doc officielle mais je n'ai pas retrouvé le lien.
Le choix des versions n'est pas un hasard. Ce message l'explique clairement: http://ubuntuforums.org/showpost.php?p=5369650&postcount=5 Pour obtenir un correctif dans n'importe quelle version (y compris LTS), il est important de suivre la procédure "Stable Release Update": https://wiki.ubuntu.com/StableReleaseUpdates C'est une des choses qu'on fait pour les clients de support chez Canonical, mais n'importe qui peut suivre la procédure - c'est assez long la première fois qu'on le fait... mais si on a les bonnes justifications et assez d'informations, c'est possible. On fait un compromis quand on utilise une "release" d'Ubuntu car les versions de logiciels sont gelées, par contre les MAJ de sécurité sont appliquées. Les nouveau feature "importants" sont souvent surestimés et dans certains environnements, un serveur web, un serveur de fichiers, un traitement de textes, le courriel, etc. restent des applications dont la plupart de fonctionalités peuvent rester gelées pendant des années. Si un éditeur de logiciel prends Ubuntu assez au sérieux, il proposera un .deb au minimum... idéalement il intégrera son logiciel au dépôts Multiverse, Universe ou même Main. Ça se fait pas en 24h, mais encore une fois c'est à la portée de ceux qui voudront s'y mettre: https://wiki.ubuntu.com/Packaging Encore une fois il est possible d'engager des développeurs (ou même Canonical) pour faire ce travail. Ultimement c'est une question de sous vs. temps vs demande/offre. Quand un éditeur propose un script qui installe mais qui ne désinstalle pas... permettez-moi de suggérer de le contacter pour demander un peu plus de détails sur cette approche douteuse. Ou bien, si vous le décidez ainsi, vivez avec le résultat. Après tout on décide de ce qu'on installe ou pas :) > Jaimerais que ubuntu sois plus documenter et/ou ameliorer pour ca > capaciter a supporter des operation manuelle. > Oh, documentation il y a - mais ça dépasse le cadre d'Ubuntu et ça s'applique pour la plupart des distributions. Pour commencer: https://help.ubuntu.com/community/InstallingSoftware https://help.ubuntu.com/community/CompilingEasyHowTo > Ex:dans freebsd le systeme vanille corespond fichier dans /usr /lib > /etc.. Tandis que les element custum sont dans /usr/local/lib > /usr/local/etc. Ce que fait en sorte que les conflits sont facile a > gerer manuelement lorsque le systeme de packet atteint c limite. Cette > facon de faire est convenable aussi dans ubuntu. Par contre, et > malheureusement les operations non-vanille se font dans les chemins du > systemes de fichier vanille. > Je ne vois pas comment "le système de packet atteint ses limites" si tu fais des opérations manuelles. C'est certain que si tu éxécutes un script générique sans l'examiner, tu auras des surprises. Parfois on peut attendre un peu, demander quelle est la procédure pour revenir en arrièrer après installation, etc. Et en passant même un .deb peut contenir des surprises :) Le "packaging" est, paraît-il, un art obscur ! > Je propose que la destination des logicielles non-maintenu dans le > depot non-vanille de ubuntu sinstalle dans /usr/local. Aussi, I'll > faut que la destination du 'make installe' soit rooter ver /usr/local. > Meme chose pour les librairie de python et compagnie installer avec le > gestionnaire de packet du language. > > Cette suggestion sera favorable pour canonical car cela facilitera le > support technique. I'll sera plus facille identifier les elements > non-vanille. Aussi les operations manuel seront plus accessible. Quand > je dit ca, je pence a freebsd ou un simple delete du /usr/local fait > le travail, quand ce dossier est bien utiliser, pour retrouver le > systeme vanille.Ce nest pas necessaire de faciliter autant la gestion > des logiciels non-vanille par > moins de cohesion avec le systeme mais une marche dans cette ideologie > pourrais ce faire dans ce sens. > > Quelles sont vos avis? > Normallement c'est déjà le cas, tous les Linux suivent le Linus Standard Base, incluant les conventions pour l'emplacement de fichiers définies dans le Filesystem Hierarchy Standard (FHS): http://www.pathname.com/fhs/pub/fhs-2.3.html plus précisemment: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY C'est pas vraiment une suggestion dont Canonical pourrait tenir en compte (d'ailleurs ce serait plutôt la communauté de développeurs et le technical board), car ce que tu décris est ce que les éditeurs qui *ne fournissent pas de package* devraient faire, si j'ai bien compris. Et pour répondre avec mon chapeau de support... dès qu'on détecte qu'un client a compilé des trucs manuellement ou a "tricotté" son système manuellement avec des applications custom sans suivre les bonnes pratiques de base... on ne peut pas trop les aider - ce n'est plus Ubuntu, d'un point de vue de support technique commercial. La saga "Automatix", ces scripts qui faisaient la pluie et le beau temps vous en dira long si vous cherchez avec Google pour les archives de discussions à ce sujet. Merci d'avoir piqué ma curiosité, ça m'a permis de réviser certaines choses ;) Ceux sur la liste qui s'y connaissent un peu plus en packaging ou sur le LSB / FHS pourront certainement en dire beaucoup plus long. A+ Fabian -- Ubuntu-quebec mailing list Ubuntu-quebec@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-quebec