Justement, pour Oracle, le service inclut de t'apprendre à installer leurs produits correctement. Tu penses bien qu'ils n'allaient pas te fournir un truc tout fait...
Puisque tu prêches pour ton logiciel notamment, je ne comprends pas très bien ce que tu attends d'un tel système puisque tu as déjà des paquets binaires de ton logiciel pour la majorité des distributions actuelles (je fais fi de Mac OSX et Windows)...
Quels sont donc les problèmes que tes utilisateurs rencontrent ?
Si les développeurs passaient un peu plus de temps à faire les paquets eux-mêmes de leurs applications, il y aurait sans doute moins de bogues car ils seraient bien obligé de se placer dans un contexte plus proche du réel que leur environnement de développement où « ça marche ».
Le travail le plus ingrat dans le développement d'un logiciel sont justement les tests et l'intégration de celui-ci avec les autres logiciels déjà en place mais c'est au moins aussi important que le développement proprement dit.
APT et RPM ont déjà une liaison avec le port RPM d'APT. Je pense que tu voulais plutôt parler de DEB et RPM. La solution vient peut-être de Smart[1], qu'Ubuntu, Mandriva et de nombreuses distributions vont peut-être choisir pour leurs futures versions.
Tout ceci abonde dans mon sens.
Si le développeur veut aller plus loin pour faire plaisir à ses utilisateurs, qu'il s'occupe alors de préparer lui-même des paquets binaires pour plusieurs distributions, au moins celles qu'il connait ou que son équipe de développement connait. De nombreux projets libres le font ainsi comme Grisbi ou Net-SNMP pour n'en citer que deux disposant à chaque nouvelle version d'un nombre conséquent de binaires.
En fait, ce problème se pose surtout pour les logiciels ludiques et bureautiques.
Je pense que leurs distributions devraient peut-être sortir du cadre des distributions.
À noter que le système Debian se trouve actuellement confronté (ou le sera très bientôt) à un problème de pertinences avec les outils de recherche se basant uniquement sur les noms et descriptions de paquets.
À tel point qu'un développeur Debian, Enrico Zini, a décidé de mettre en application les travaux d'un mathématicien et bibliothécaire indien, Shiyali Ramamrita Ranganathan[1], avec DebTags[2]. Si le format RPM pouvait adopter ce système de tags (tout comme celui de Debconf d'ailleurs), il y a gagnerait en fonctionnalité et les deux systèmes y gagnerait en harmonie.
Il n'y a pas qu'APT qui soit un bon système chez Debian.
Il faut savoir aussi que la différence majeure entre les deux formats est que les RPM basent leurs dépendances sur les fichiers là où les DEB s'appuient uniquement sur le système de dépendances.
Par plantage, il faut souvent comprendre « problème de dépendances de compilation » que l'utilisateur débutant a du mal à cerner aux vues des nombreuses questions sur le sujet qui pollue les listes et autres forums.
Ce que j'en voie avec ma mauvaise fois trollesque légendaires, c'est un moyen pour LSB (et ses principaux promoteurs) de 'reprendre un peu le devant de la scène' dans un univers linux libre qui s'éclate sous l'effet d'un nombre croissant de distributions communiquantes, et de positionnement, face au respect de la gpl, parfois divergents.
Quand on sait qui est le principal instigateur (et « CTO » du LSB) de cette initiative, on comprend mieux : Ian Murdock.
Il est clair que les logiciels proprios qui veulent canibaliser le libre (prime au premier entrant) sont les premiers interessés d'une initiative comme cela. Par effet de 'renommé' ce groupe de travail communiquerait (peut être avec raison, question de goûts) facilement sur les grosses boites proprios qui porteraient des applis proprios sous linux, ce qui fragiliserait un peu le délicat écosystème (dans le sens économique) du libre.
Quand on voit quels sont les principaux acteurs (Progeny, RedHat et Novell), on comprend également mieux pourquoi il y aurait intérêt à créer un tel système afin de permettre une installation plus aisée des logiciels, fussent-ils propriétaires.
Oui mais par défaut, ça s'installe dans /usr/local.
Installer des fichiers directement sous /usr, c'est s'opposer aux systèmes rpm et dpkg car les risques de conflits sont loin d'être mineurs.
Oui mais c'est ce qui présente également le plus de risque de conflits avec le système installé et la gestion de paquets.
Je préfère encore que les utilisateurs compilent leurs logiciels à la ./configure; make; make install, au moins, ça ira tout droit dans /usr/local
Si AutoPackage utilise /usr par défaut parce qu'ils n'ont pas de solutions pour ajouter les chemins de /usr/local dans la configuration système, excuse-moi, mais c'est de la pure fainéantise : il suffirait d'ajouter /usr/local/lib dans /etc/ld.so.conf et de modifier le $PATH dans un /etc/profile. Et s'ils ne sont pas capables de deviner le shell utilisé par le système...
Utiliser /usr parce que /usr/local n'est pas intégré dans les chemins par défaut sur la majorité des distributions est une mauvaise excuse.
Comment ne suis-je pas étonné de voir le fondateur de Debian et surtout de Progeny venir encore une fois à l'assaut avec sa prétendue compatibilité binaire que Marck Shuttelworth a déjà maintes fois démonté.
S'agissant principalement de Logiciels Libres, le modèle d'installation des logiciels sous Windows n'est guère applicable sous Linux.
Pour ce faire, il faudrait que les éditeurs de logiciels tiers fournissent des paquets binaires compatibles comme le font actuellement les éditeurs tiers de logiciels sous Windows, point barre. Évidemment, ils devront le faire pour chaque distribution, le problème soulevé est toujours le même...
Que ceux qui prétendent ainsi faciliter la vie de leurs utilisateurs fassent donc le nécessaire pour que ces derniers puissent trouver plus rapidemment des versions binaires des logiciels libres pour leurs distributions préférées au lieu d'ergoter sur un fumeux et éventuel « standard ».
Et qui se cachent bien d'appliquer des directives qui seraient certainement plus populaires mais qui nuiraient aux intérêts économiques (de certains grands groupes). Exemple : une plainte existant aux USA et permettant à un certain nombre de consommateurs de porter plainte d'un seul élan contre un fournisseur particulier. Mais ça, le MEDEF n'en a surtout pas voulu.
Les berbères ne sont pas d'origines arabes et pourtant bien maghrébins.
De même, les arabes viennent d'Arabie Saoudite, pas du Maghreb. Toutefois, depuis la colonisation arabe, la plupart des peuples situés au Nord du Sahara parle arabe (et encore, le plus souvent un arabe local que les autres ont souvent du mal à comprendre).
De toutes manières, on ne devrait pas parler d'une personne en fonction de son apparence, c'est discriminatoire et les termes deviennent péjoratifs.
Tu ne pourras pas de toutes manières installer de RPM via apt depuis le lien que tu as fournis. Il y manque tous les fichiers Release et Packages nécessaires à APT pour savoir ce qu'il y a de disponible et où les trouver.
Une source apt pour RPM prendra plutôt la forme suivante :
Par défaut, tu n'auras pas yum sous RHEL car ce outil n'est disponible qu'avec Fedora. L'outil de RHEL se nomme up2date et nécessite d'enregistrer le serveur auprès du RHN pour pouvoir récupérer les paquets RPM édités par RedHat et pour RHEL. Utiliser une RHEL sans RHN n'a d'ailleurs pas de sens en soit car il existe d'autres alternatives (Fedora mais aussi CentOS, pour ne parler que des distributions les plus proches) si tu ne souhaites pas payer.
Pour ceux qui se posent la question mais qui sont trop fainéants pour chercher, il s'agit de l'auteur original de Packet Filter dit pf, le parefeu d'OpenBSD. Maintenant, qu'on soit l'auteur de pf ou pas ne donne pas forcément plus de crédit pour un patch sur OpenSSH (à part auprès des développeurs d'OpenSSH, sans doute).
Mouais...
C'est bien gentil la « VMware Appliance » mais c'est le seul moyen fourni pour tester leur application. S'appuyer sur le succès d'OpenOffice.org, Tomcat, etc., c'est bien mais le projet n'a l'air ni libre ni gratuit.
C'est fort dommage...
Je citerais aussi le projet Alfresco car après tout, tous ces outils servent avant tout de base documentaire pour l'entreprise. http://www.alfresco.com/
Mais j'aimerais bien un outil de ce genre qui ne soit pas écrit en Java, même si c'est libre, maintenant.
Comme si la sécurité par l'obscurantisme était un gage de tranquilité...
Il doit y avoir sans doute plusieurs étudiants pour en avoir déjà percé les failles.
Alors pourquoi est-ce que Microsoft ou même Adobe continue de vivre tranquillement ? Microsoft Windows, Office ou Acrobat Reader ne sont pas des logiciels « grand public » ?
Je dirais plutôt que la concurrence déloyale de Microsoft en intégrant certains logiciels au sein même de son système d'exploitation (on n'a plus besoin de WinZip avec Windows XP...) à amener plus d'une entreprise souvent innovante à mettre la clé sous la porte. Développer des logiciels sous Windows, sauf niche, est un suicide financier.
[^] # Re: ça peut pas marcher ?
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 3.
[^] # Re: Ça n'arriveras jamais
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 3.
Quels sont donc les problèmes que tes utilisateurs rencontrent ?
[^] # Re: .
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 2.
[^] # Re: .
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 2.
Le travail le plus ingrat dans le développement d'un logiciel sont justement les tests et l'intégration de celui-ci avec les autres logiciels déjà en place mais c'est au moins aussi important que le développement proprement dit.
[^] # [ÉTAIT: Re: . ] Smart est sans doute la solution
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 2.
[1]: http://labix.org/smart
[^] # Re: .
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 2.
Si le développeur veut aller plus loin pour faire plaisir à ses utilisateurs, qu'il s'occupe alors de préparer lui-même des paquets binaires pour plusieurs distributions, au moins celles qu'il connait ou que son équipe de développement connait. De nombreux projets libres le font ainsi comme Grisbi ou Net-SNMP pour n'en citer que deux disposant à chaque nouvelle version d'un nombre conséquent de binaires.
En fait, ce problème se pose surtout pour les logiciels ludiques et bureautiques.
Je pense que leurs distributions devraient peut-être sortir du cadre des distributions.
[^] # Re: Difficile
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 4.
À tel point qu'un développeur Debian, Enrico Zini, a décidé de mettre en application les travaux d'un mathématicien et bibliothécaire indien, Shiyali Ramamrita Ranganathan[1], avec DebTags[2]. Si le format RPM pouvait adopter ce système de tags (tout comme celui de Debconf d'ailleurs), il y a gagnerait en fonctionnalité et les deux systèmes y gagnerait en harmonie.
Il n'y a pas qu'APT qui soit un bon système chez Debian.
Il faut savoir aussi que la différence majeure entre les deux formats est que les RPM basent leurs dépendances sur les fichiers là où les DEB s'appuient uniquement sur le système de dépendances.
[1]: http://fr.wikipedia.org/wiki/Shiyali_Ramamrita_Ranganathan
[2]: http://debtags.alioth.debian.org/
[^] # Re: Difficile
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 4.
[^] # Re: Beurk
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 2.
[^] # Re: Faux problèmes à mon sens.
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 2.
[^] # Re: Faux problèmes à mon sens.
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 3.
Quand on sait qui est le principal instigateur (et « CTO » du LSB) de cette initiative, on comprend mieux : Ian Murdock.
Quand on voit quels sont les principaux acteurs (Progeny, RedHat et Novell), on comprend également mieux pourquoi il y aurait intérêt à créer un tel système afin de permettre une installation plus aisée des logiciels, fussent-ils propriétaires.
[^] # Re: .
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 4.
Installer des fichiers directement sous /usr, c'est s'opposer aux systèmes rpm et dpkg car les risques de conflits sont loin d'être mineurs.
[^] # Re: .
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 7.
Je préfère encore que les utilisateurs compilent leurs logiciels à la ./configure; make; make install, au moins, ça ira tout droit dans /usr/local
Si AutoPackage utilise /usr par défaut parce qu'ils n'ont pas de solutions pour ajouter les chemins de /usr/local dans la configuration système, excuse-moi, mais c'est de la pure fainéantise : il suffirait d'ajouter /usr/local/lib dans /etc/ld.so.conf et de modifier le $PATH dans un /etc/profile. Et s'ils ne sont pas capables de deviner le shell utilisé par le système...
Utiliser /usr parce que /usr/local n'est pas intégré dans les chemins par défaut sur la majorité des distributions est une mauvaise excuse.
# Tiens, Ian Murdock parmi les « personnes-clés »
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 3.
S'agissant principalement de Logiciels Libres, le modèle d'installation des logiciels sous Windows n'est guère applicable sous Linux.
Pour ce faire, il faudrait que les éditeurs de logiciels tiers fournissent des paquets binaires compatibles comme le font actuellement les éditeurs tiers de logiciels sous Windows, point barre. Évidemment, ils devront le faire pour chaque distribution, le problème soulevé est toujours le même...
Que ceux qui prétendent ainsi faciliter la vie de leurs utilisateurs fassent donc le nécessaire pour que ces derniers puissent trouver plus rapidemment des versions binaires des logiciels libres pour leurs distributions préférées au lieu d'ergoter sur un fumeux et éventuel « standard ».
[^] # Re: Ceci est une pub
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Résultats du concours LinuxFr « Lettre au Père Noël ». Évalué à 2.
[^] # Re: Faut quand même un peu garder les pieds sur terre.
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal L'Europe telle que nous l'avons perdue. Évalué à 2.
[^] # Re: 3 Europes
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal L'Europe telle que nous l'avons perdue. Évalué à 2.
[^] # Re: rien de neuf
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal L'Europe telle que nous l'avons perdue. Évalué à 1.
Les berbères ne sont pas d'origines arabes et pourtant bien maghrébins.
De même, les arabes viennent d'Arabie Saoudite, pas du Maghreb. Toutefois, depuis la colonisation arabe, la plupart des peuples situés au Nord du Sahara parle arabe (et encore, le plus souvent un arabe local que les autres ont souvent du mal à comprendre).
De toutes manières, on ne devrait pas parler d'une personne en fonction de son apparence, c'est discriminatoire et les termes deviennent péjoratifs.
La langue Arabe : http://fr.wikipedia.org/wiki/Arabe
Pays de langue arabe : http://fr.wikipedia.org/wiki/Image:Arab_world.png
Les Berbères : http://fr.wikipedia.org/wiki/Berb%C3%A8re
# Notion de dépôts APT
Posté par Raphaël SurcouF (site web personnel) . En réponse au message apt-get & sources.list. Évalué à 2.
Une source apt pour RPM prendra plutôt la forme suivante :
# Le RedHat Network
Posté par Raphaël SurcouF (site web personnel) . En réponse au message Expert RHEL. Évalué à 1.
https://rhn.redhat.com/help/about.pxt
[^] # Re: Pourquoi un nouveau patch ?
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal OpenSSH : un patch PKI. Évalué à 1.
Interview de Daniel Hartmeier sur kerneltrap :
http://kerneltrap.org/node/477
[^] # Re: Vu autrement ...
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal OpenOffice, l'adversaire numéro un de Microsoft Office 2007, avec Sophie Gautier sur O1net. Évalué à 1.
C'est bien gentil la « VMware Appliance » mais c'est le seul moyen fourni pour tester leur application. S'appuyer sur le succès d'OpenOffice.org, Tomcat, etc., c'est bien mais le projet n'a l'air ni libre ni gratuit.
C'est fort dommage...
[^] # Re: Vu autrement ...
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal OpenOffice, l'adversaire numéro un de Microsoft Office 2007, avec Sophie Gautier sur O1net. Évalué à 2.
http://www.alfresco.com/
Mais j'aimerais bien un outil de ce genre qui ne soit pas écrit en Java, même si c'est libre, maintenant.
[^] # Re: une liste serait-elle disponible?
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Et si le secteur public libérait ses propres logiciels ?. Évalué à 2.
Il doit y avoir sans doute plusieurs étudiants pour en avoir déjà percé les failles.
[^] # Re: Attention launchpad
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Mark Shuttleworth invite les développeurs OpenSUSE à rejoindre Ubuntu et suscite la polémique. Évalué à 3.
Je dirais plutôt que la concurrence déloyale de Microsoft en intégrant certains logiciels au sein même de son système d'exploitation (on n'a plus besoin de WinZip avec Windows XP...) à amener plus d'une entreprise souvent innovante à mettre la clé sous la porte. Développer des logiciels sous Windows, sauf niche, est un suicide financier.