Emmanuel Seyman a écrit 284 commentaires

Parce que si tu reprends les src.rpm et que tu rebuildes, tu devrais te retrouver dans le même cas.

CentOS ne peut pas faire ça parce que ça revient à utiliser la marque Red Hat sans son autorisation.
Ils doivent donc modifier les .spec tout en respectant la compatibilité binaire (ce qui n'est pas toujours évident).

Sous Fedora, ça fait environ 3000 paquetages.

11 000 paquets sources, 20 000 paquets binaires.

J'arrête machineA puis la relance, lxc-ls chez moi me montre deux machines machineA !

Le lxc-ls de Debian Squeeze génère 2 listes. La première est celle de toutes les conteneurs lxc sur la machine (activés où pas). La deuxième est celle des conteneurs activés. Il est donc tout à fait normal que machineA revienne 2 fois.

Et Blosxom (http://blosxom.sourceforge.net/).

> - Le manque de paquets. Les paquets sont rares sur Fedora et en plus ils en refusent.

Le manque de paquets tient essentiellement dans le fait que Fedora (dans son aspect communautaire) est plus jeune que Debian (8 ans contre 17+). Le retard se comble petit à petit, de release en release.

> Ton dernier point c'est le meme style que la ferme de build de opensuse et les ppa de ubuntu?

Oui, c'est ça. Les développeurs Fedora ont maintenant la possibilité de proposer des applications qu'ils ne peuvent pas mettre dans le dépôt officiel (on parle déjà d'en créer un pour postgresql 9, qui est sortie après le freeze de Fedora 14).

> Tu veux qu'ils fassent de l'argent avec quoi ?

Dans toutes les interviews que j'ai lu, Matt Asay propose de très bonnes idées pour rendre Canonical profitable (la plupart sont des solutions basés sur le Cloud Computing, en utilisant un poste Ubuntu comme terminal distant).

Ensuite, ça peut ne pas marcher et ça peut être suffisant pour rendre Canonical profitable mais, ça, c'est une autre question.

Je ne l'ai compris ni dans un sens ni dans un autre mais tous les interviews de Mark S. et de Matt Asay me font penser qu'on est dans la deuxième situation.

> Il n'avait pas expliqué qu'elle n'était pas "profitable" plutot?

Je suis certain d'avoir entendu "aujourd'hui, Canonical perd de l'argent" mais j'imagine que ça a du être enregistré quelque part.

> Parce que c'est lui qui a dit qu'en 2009 elle avait atteint "presque" l'équilibre.

Il l'a aussi dit en 2008 et en 2010.

> Ubuntu est une société privée

Ubuntu est une distribution Linux. Tu penses peut-être à Canonical lorsque tu parles de société privée.

> selon ses dirigeants elle est à l'équilibre.

Marc Shuttleworth avait expliqué pendant la Ubuntu Party 9.10 que Canonical n'était pas à l'équilibre. C'est pour tenter de remédier à ça que Matt Asay a été embauché.

> (il faut installer un depot en plus et c'est pas hyper intuitif)

Quelle partie n'était pas intuitif ?

J'avoue que j'aime beaucoup pouvoir cliquer sur un lien, cliquer "OK", donner le mot de passe root de la machine et me retrouver avec un nouveau dépôt de configuré.

> Red Hat Linux n'était pas une distribution communautaire et, de ce fait, on ne peut pas la prendre en compte.

Mea culpa, je m'aperçois qu'il existe des collections Red Hat Linux 8 et 9. Le projet Fedora est donc la continuation de Fedora Linux (commencé en juin 2002, à peu près).

> Il faut compter l'âge de Fedora comme étant l'âge de Red-Hat si tu veux faire cette comparaison.

Non. Red Hat Linux n'était pas une distribution communautaire et, de ce fait, on ne peut pas la prendre en compte. Ou alors, faut m'expliquer pourquoi il y avait seulement 358 paquets sources dans la collection Fedora 1.

Pourquoi j'ai parlé de stabilité, moi ? s/stabilité/maturité/ et mea culpa.

> Remplacé par Systemd ? C'est déjà décidé ?

C'est en cours de discussion sur la liste de discussion devel.
http://lists.fedoraproject.org/pipermail/devel/2010-May/1365(...)

> Fedora a quand même beaucoup moins de paquets disponibles que debian, quelqu'un saurait à quoi cela est dû ?

Fedora est beaucoup plus jeune que Debian (6,5 ans contre 17) et n'a pas encore rattrapé son retard.

En regardant le nombre de paquets dans les collections Fedora et en projetant dans le futur, le nombre de paquets ne rattrapera celui de Debian que pour Fedora 19.

> Je me pose d'ailleurs la question pourquoi cela a ete aussi difficile a mettre en place sur Fedora?

Le mainteneur de python dans la distribution a longtemps été opposé à ce que deux versions coexistent sur une version de la distribution. C'est en constatant que python 3 n'est pas suffisamment stable pour être la seule version dans Fedora 13 qu'il a finalement accepté cette solution (deuxième problème qui n'a pas les mêmes symptômes que le premier, AMHA).

Les SS2L s'en sortent plutôt bien, les éditeurs de distro, dont Mandriva, moins bien à franchement plus mal. On peut se demander si les SS2L ne sont pas plus aptes à vendre et à assurer du service que les éditeurs.

Deux conceptions s'affrontent (pour, en fait, dire la même chose) :
* Les SS2L sont en réalité des éditeurs car elles proposent du support, de la formation, l'intégration dans le SI du client, ...
* Les éditeurs de Logiciels Libres sont en réalité des SS2L car en plus de leur métier d'éditeur, ils proposent la personnalisation du logiciel, le développement de greffons, ...

En général, on se quitte vers 17-18H

Je vois pas le problème, l'user a plusieurs journaux et c'est pas écrit en dernière ligne "[...]".

C'est une dépêche qui raconte un peu n'importe quoi sur un éditeur de distribution, écrit par quelqu'un qui oublie de préciser qu'il était (à l'époque) employé par un autre éditeur de distribution (donc concurrent de la première).

Et, bien sur, j'ai oublié de préciser que je travaille pour Linagora.

On aime que les choses soient claires ici.

Ah bon ? Dans ce cas, il va falloir m'expliquer la publication d'au moins un article précédant : http://linuxfr.org//2002/02/28/7303.html

> > peut être que redhat a voulu créer un vrai rpm communautaire

> Oui. Mais constatons que ça ne prend pas. Red Hat fait toujours le gros du boulot et a du embaucher spécifiquement pour rpm.

J'ai du mal à imaginer une communauté très actif autour de rpm et je serai très surpris si Red Hat pensait se retrouver avec des centaines de contributeurs.

Le rpm de rpm.org contient des correctifs de Pixel (le mainteneur de rpm dans Mandriva jusqu'à il y a peu) et ceux des mainteneurs rpm de Suse (désolé, pas de noms à fournir). On peut espérer que la version 4.6 sera adoptée par les trois distributions et que tout le monde mutualisera ses efforts de développement autour de celle-ci plutôt que de re-inventer la roue à chaque fois. Si ça se fait, ce sera déjà un grand pas en avant.

Non.

Plutot que de contribuer à des distributions déjà existante, qui incluent déjà 80% de ces outils, et qui acceptent des contributions externes ?

Je pense qu'il est plus rapide de faire une distribution dédiée que de contribuer les logiciels manquants à une distribution puis de faire le meta-paquet qui va bien.
On peut toujours, une fois la preuve de concept créée, contribuer ce qui a été fait à la distribution upstream.