Afin de mettre un terme à ces discussions stériles et de pouvoir à nouveau avancer, les mainteneurs Debian du logiciel, à savoir Eduard Bloch et Joerg Jaspert, ont pris la difficile décision de créer un fork à partir de la dernière version considérée libre. Espérons que cdrkit (nom du nouveau projet "forké") sera rapidement adopté et que le développement reprenne le pas sur les discussions. Les problèmes qu'a rencontré Debian ne sont pas uniques à la distribution, et les rumeurs de fork se faisaient nombreuses. On pourra citer, principalement deux types de problèmes.
- Joerg Schilling n'accepte pas qu'on applique des patches qu'il n'a pas approuvés à ses sources ; il clame en particulier que cela pourrait nuire à sa réputation et a exprimé moult menaces de procès. Il demande qu'aucune modification ne soit appliquée à ses sources sous peine d'enfreindre sa marque de commerce cdrecord.
- Le nouveau système de compilation (Schily makefilesystem) est fourni sous licence CDDL incompatible avec la licence GPL du code. Ceci rend théoriquement impossible la distribution de binaires compilés à partir de ces sources. D'autres limitations dans les sources introduisent certaines sections invariantes, au mépris de la GPL. L'ensemble est donc soumis à un gros flou juridique.
En revenant à la dernière version clairement sous GPL et en appliquant les patches, les développeurs ont pu fournir quelque chose d'à la fois libre et résolvant un certain nombre de problèmes. On pense en particulier au fait que le binaire de cdrecord doive être positionné en setuid root, source de moult discussions enflammées avec les développeurs du noyau. Wodim (l'outil qui remplace cdrecord dans cdrkit) n'a pas ce besoin.
Aller plus loin
- L'annonce (5 clics)
- cdrkit (47 clics)
- Les problèmes de licences (6 clics)
- Le changelog (7 clics)
# Utilité ?
Posté par Moonz . Évalué à 10.
Et franchement, je trouve que pousser un projet plus modulaire comme libburn aurait été une meilleure idée...
M'enfin, ils font ce qu'ils veulent, après tout...
[^] # Re: Utilité ?
Posté par symoon . Évalué à 10.
Et franchement, je trouve que pousser un projet plus modulaire comme libburn aurait été une meilleure idée...
J'imagine qu'il faut aussi adapter tous les logiciels qui utilisent cdrecord comme backend pour utiliser libburn à la place, est-ce si facile ?
(Je me pose juste une question)
À noter également, que les responsables du paquet cdrtools et désormais développeurs de cdrkit invitent les développeurs des autres distributions à les rejoindre pour développer cdrkit.
[^] # Re: Utilité ?
Posté par Derochette Robert . Évalué à 10.
Il suffirait de continuer à fournir une commande cdrecord utilisant la fameuse libburn, et le problème que tu exposes est réglé.
[^] # Re: Utilité ?
Posté par GigaHertz . Évalué à 4.
Non, juste prevenir les developpeurs de "frontend" qui de toute façon doivent être au courant :)
Pourquoi avoir peur de proposer le changement?
[^] # Re: Utilité ?
Posté par Derochette Robert . Évalué à 1.
Les développeurs de frontend ne doivent pas être au courant d'une modification qui serait propre à Debian et pas à toutes les distributions Linux. Si dans un logiciel, on veut modifier l'implémentation d'un composant de base, il faut s'assurer que la nouvelle implémentation se comporte en tout point comme l'ancienne. C'est la raison pour laquelle, à court terme, je pense qu'une couche de compatibilité entre l'ancien cdrecord et le nouveau utilisant la fameuse libburn est indispensable.
Maintenant, à long terme, si un nouveau programme s'impose comme le standard des programmes de gravure sous linux, là on peut commencer tout doucement à imposer des modifications aux concepteurs de frontend. Par exemple, comme sun le fait avec java 1.5, en affichant des warning quand ton programme utilise une partie de l'API qui est "depréciée", puis plus tard, interdire complètement la compilation du programme.
[^] # Re: Utilité ?
Posté par Frédéric-Emmanuel Picca . Évalué à 5.
[^] # Re: Utilité ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 7.
Cependant, il n'est pas si simple de remplacer un logiciel comme cdrecord. Il y a d'innombrables contournements pour des bugs de matériel, et créer un fork nécessite d'avoir une base d'utilisateurs suffisamment large pour maintenir cette base de contournements.
On est déjà débarrassés de cdrecord pour la gravure de DVD, car dvd+rw-tools joue ce rôle, mais ça manquait pour les CD.
[^] # Re: Utilité ?
Posté par tuiu pol . Évalué à -1.
# Historique de dvdrtools
Posté par Jean-Christophe Berthon (site web personnel) . Évalué à 6.
Effetivement, comme sous entendu ci-dessus, le projet dvdrtools est déjà un fork de cdrtools. Par contre, je n'arrive pas à retrouver l'historique de ce fork. Google n'a pas pu m'aider :-(
Quelqu'un aurait-il des éléments de réponse ?
Merci,
Jean-Christophe
# Embranchement
Posté par mammique . Évalué à -2.
Debian forke embranche cdrtools?
http://fr.wikipedia.org/wiki/Fork#Fork_d.27un_projet_informa(...)
[^] # Re: Embranchement
Posté par Calim' Héros (site web personnel) . Évalué à 6.
Debian clone cdrtools
Sous l'impulsion de Debian, cdrtools bifurque
[^] # Re: Embranchement
Posté par Zakath (site web personnel) . Évalué à 9.
Debian fourchette cdrtools.
[^] # Re: Embranchement
Posté par yoplait . Évalué à 3.
[^] # Re: Embranchement
Posté par abc . Évalué à 2.
;-)
[^] # Re: Embranchement
Posté par Calim' Héros (site web personnel) . Évalué à 3.
==>[]
[^] # Re: Embranchement
Posté par Calim' Héros (site web personnel) . Évalué à 4.
J'y retourne ===> []
# Plus de setuid? Enfin?...
Posté par creak (site web personnel) . Évalué à 2.
Je croyais que cdrecord était en setuid car le device du graveur était accessible en écriture seulement avec les droits root. Qu'est-ce qui fait que maintenant ça marche?
Pour ce qui est du fork, je pense que les conditions de départ ont l'air justes pour qu'un fork soit fait. Je comprend pas le principe de dire que l'ont fait un projet libre si on ne supporte pas que quelqu'un d'autre puisse corriger ton code...
[^] # Re: Plus de setuid? Enfin?...
Posté par Jar Jar Binks (site web personnel) . Évalué à 6.
Non, udev est capable tout seul de créer les devices avec les bonnes permissions :
brw-rw---- 1 root cdrom 22, 0 2006-09-04 15:08 /dev/hdc
Le vrai problème, c'est que les développeurs du kernel ont rendu (sûrement pour de bonnes raisons) certaines ioctl SCSI inaccessibles en tant qu'utilisateur normal. Joerg Schilling s'en est beaucoup plaint alors qu'il suffisait de corriger le logiciel pour ne pas utiliser ces ioctl.
# quelle version ?
Posté par fabien . Évalué à 6.
c'est pour voir s'ils partent de loin ou pas.
j'ai trouvé ce message sur le ML de fedora : https://www.redhat.com/archives/fedora-advisory-board/2006-A(...)
mais ils ne précisent pas a partir d'ou ils sont partie.
merci.
# La cathédrale et le bazar
Posté par salvaire . Évalué à 4.
Il a programmé un logiciel (seul?). Il met à disposition le code source. Mais faut pas en demander plus. C'est parfaitement son droit.
L'ennui c'est qu'il n'y a pas d'autre alternative (mise à part dvdrtools) pour Linux, que le code source ne doit pas être facile à digérer, et que l'obtention de graveurs auprès des constructeurs n'est pas aisé.
Je pense que cette affaire illustre une difficulté du libre qui concerne surtout les logiciels -indispensables- et pas -facile- à forker ou à reprogrammer depuis le début. L'intérêt/vision personnel n'est pas compatible avec l'intérêt/vision de tous le monde. C'est un cas similaire à XFree, et il y a plein d'autre exemple. À l'avenir il faudrait que de tels projets soit mieux encadré par un collège représentatif des différents acteurs (du libre). De plus Joerg est probablement la seule personne à bien connaître le code. Qu'adviendrait il si il avait un accident? Je connais d'autre cas comme cela, un crash d'avion pour une conférence et c'est le désastre ...
[^] # Re: La cathédrale et le bazar
Posté par Anonyme . Évalué à 10.
un crash d'avion, même sans conférence, c'est en général considéré comme un désastre :-)
[^] # Re: La cathédrale et le bazar
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
Pas s'il était rempli d'avocats. Ou alors il restait un strapontin de libre...
[^] # Re: La cathédrale et le bazar
Posté par Croconux . Évalué à 10.
Mais personne ne lui en demande plus. Jorg a fais un excellent boulot au début de cdrtools mais il faut bien reconnaitre que dernièrement il est devenu un problème majeur, tout comme l'ancien "board" d'XFree était devenue un boulet à trainer.
Il faut quand même rappeler qu'il a longtemps refusé d'intégrer les patchs visant à supporter la gravure de DVD (ce qui prouve au passage qu'il est loin d'être le seul à maitriser le code) pour la simple raison qu'il distribuait une version commerciale incluant cette fonctionnalité. C'est d'ailleurs à cette époque que 1 ou 2 forks se sont montés car chaque distribution patchait le bousin dans son coin en incluant tel ou tel patch d'où quelques problèmes. Il me semble qu'ils ont été abandonnés lorsque le support des DVD+/-R a été officiellement ajouté.
Ensuite il y a eu la gue-guerre à propos des noms des devices. Pour mémoire jusqu'au noyau 2.4, il fallait passer par l'émulation SCSI pour graver un CD. Sous le 2.6 ce n'est plus nécessaire mais pourtant il faut toujours appeler cdrecord avec des paramètres du genre dev=1,0,0 (et pas dev=/dev/hdb) même si on ne se sert pas de l'émulation SCSI sous peine de se taper un message d'insulte disant que c'est "pas bien", que c'est contraire à la vision du maître,...
Et dernièrement il se met à mixer des codes sous licenses incompatibles. Non, franchement il y a des moments où il faut couper les ponts. Oui, c'est lui qui a créé le logiciel au départ mais il l'a mis sous une license libre. Maintenant s'il n'est pas content de ne pas controler son joujou c'est son problème.
# CMake
Posté par Mathieu Malaterre (site web personnel) . Évalué à 3.
# Super !
Posté par Victor STINNER (site web personnel) . Évalué à 8.
Haypo
[^] # Re: Super !
Posté par Sylvain Briole (site web personnel) . Évalué à 6.
Le "truc très bizarre" c'est (c'était) quand même une pierre essentielle du système X11 originel!
C'était un des rares systèmes qui permettaient de générer des Makefile en fonction de l'environnement disponible à l'époque où les autotools n'existaient pas.
[^] # Re: Super !
Posté par ColonelMoutarde . Évalué à 3.
[^] # Re: Super !
Posté par Philippe F (site web personnel) . Évalué à 2.
- XEmacs : l'original et le fork cohabitent plus ou moins bien encore
- gcc : la fork a remplace l'original au bout d'un moment. Si je me souviens bien, c'etait sur des histoires de support de l'objet a un moment ou RMS preferait que gcc ne fasse que du C.
Par contre, il y a des millards de forks rates. C'est _difficile_ de faire vivre un projet et nombreux sont les naifs qui pensent y arriver tout seul.
# Mangez des beignets, mangez-en!
Posté par ouah (site web personnel) . Évalué à 2.
# Gentoo avec Debian
Posté par Bapt (site web personnel) . Évalué à 10.
http://planet.gentoo.org/developers/metalgod/2006/09/05/gent(...)
cdrkit est déjà dans l'arbo des packages, mais masqué (cad unstable) et passera en ~arch (cad testing) dès que suffisament de tests auront été effectués.
Les développeurs de gentoo travaillent énormément en amont, récupérant les patchs des autres distributions, développant les leurs, et travaillant avec les développeur en amont pour faire directement intégrer leur patchs (biensûr ils ne sont pas les seuls), Les devs debian proposent des accès "commit" aux sources, ce qui intéresse donc particulièrement gentoo.
[^] # Re: Gentoo avec Debian
Posté par Terata Salokine . Évalué à 1.
Je trouve très intéressant ce travail collaboratif entre Gentoo et Debian !!
J'aime voir des synergies comme celle-ci. Elles sont rassurantes, et montrent l'enthousiasme, l'intérêt et l'importance de faire réussir ce nouveau projet.
D'ailleur, existe-il déjà un site officiel du package cdrkit ? Un espace présentant l'outils, et ouvert aux questions "utilisateurs" (forum, wiki ...etc)?
@+
et longue vie à ce projet.
Salokine
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.