Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de mildred :
- [09/12@18:40] Blender et Crystal Space : Projet Abricot
- [08/11@10:12] Un meilleur shell
- [07/10@18:27] Comment vous sauvegardez ?
- [23/09@22:36] myip.fr: le pire des FAI !
- [20/09@18:39] Temps de démarrage: Mac OS X contre Linux
- [01/07@10:47] Détection du format de fichier, ma solution à implémenter
- [09/06@21:25] En finir avec libmagic
- [05/06@23:07] Xorg et Mac OS X
- [28/03@18:15] Le vote électronique décrié sur TF1 à 20h
- [03/02@22:09] Les OGM sont ils dangereux pour la santé ?
- [22/01@22:28] Somutions contre le SPAM ?
- [17/01@19:40] Crystal Space 1.0 est enfin sorti !
- [26/12@14:01] séparateur décimal dans Open Office . org
- [12/10@18:23] je DÉTESTE Ubuntu !!!
- [24/09@00:57] Remplacer votre ~/.Xmodmap
- [16/09@11:55] Que se passe-t-il sur LinuxFR ?
- [29/06@10:37] OpenID : l'authentification décentralisée.
- [16/10@01:09] un concept de lecteur de mails particulier
- [08/09@02:03] Navibar ... une excellante initiative. A quand standardisé au W3C ?
- [06/09@01:48] Une alternative à LaTeX fait main
Journal : Problèmes d'installation des logiciels : paquets sources ?
Posté par Mildred (Jabber id, page perso, ) le 09 décembre 2007Une problématique que je trouve importante pour nos bureaux libres concerne à mon avis l'installation des logiciels tiers. Pourquoi donc me dites-vous ? C'est vrqi, nous avons quand même les packages qui sont vraiment pratiques. Cependant ...
je ne remet pas en cause les packages, au contraire. Ils sont vraiment une pièce maîtresse du système. Cependant, ils ne nous permettent que d'installer des logiciels spécifiquement pour la distribution qu'on a installé. Et les logiciels non packagés ... tant pis pour nous.
la solution qui nous reste, c'est quoi ? 0install, klik, autopackage, compilation à la main dans /usr/local ? Certaines de ces solutions ont l'air intéressantes ... mais il y a la aussi le problème de la limite du nombre de logiciels packagés. Et pour la compilation à la main dans /usr/local, elle présente deux inconvénients majeurs:
- ce n'est pas intégré au système de paquets
- il faut un certain niveau pour être capable de compiler soi même des tarball sources. Surtout si des problèmes surviennent pendant la compilation.
Une autre solution qu'on trouve dans la distribution ArchLinux, c'est AUR, c'est un repository de scripts qui peuvent automatiquement télécharger la source depuis Internet et créer un paquet ArchLinux. Un grand avantage c'est que c'est partagé, donc il est du coup possible à n'importe qui de packager le soft qu'il veut et le proposer aux autres.
Un tel script (appelé PKGBUILD) est très simple, c'est en fait un script shell qui a la structure suivante:
pkgname=...
pkgver=...
...
makedepends=(make gcc ...)
depends=(glibc ...)
source=(http://.../${pkgname}-${pkgver}.tar.gz)
build(){
cd "$startdir/src/$pkgname-$pkgver"
./congifure --prefix=/usr && make && make DESTDIR="$startdir/pkg" install
}
Comme vous le voyez, n'importe qui qui est capable de compiler un logiciel dans /usr/local peut faire un PKGBUILD et pour le coup intégrer son logiciel correctement à la distribution.
Quelque chose d'encore mieux, il existe un logiciel appelé yaourt qui permet en une seule ligne de compiler un logiciel à partir des PKGBUILD sur AUR en même temps que ses dépendances, un peu comme portage sur gentoo. Vraiment génial.
Seulement, si tout était aussi bien, ... En fait j'ai décidé il y a peu d'abandonner ArchLinux au profit de Fedora 8. Pourquoi ? Tout simplement parce qu'ArchLinux est une distribution pour utilisateurs expérimentés ... Et je fesait un peu trop d'administration système à mon goût. Je voulais quelque chose d'un peu mieux, et lorsqu'on regarde des projets de Fedora comme ceux-ci, ca donne envie:
- http://fedoraproject.org/wiki/Features/OneSecondX
- http://fedoraproject.org/wiki/Features/RandrSupport
- http://fedoraproject.org/wiki/Releases/FeatureBetterStartup
- http://fedoraproject.org/wiki/Features/FedoraElectronicLab
- http://fedoraproject.org/wiki/Features/EFI
Donc me voila sous Fedora ... C'est très bien, j'ai un boot graphique avec X11, l'administration est facilitée par les nombreuses petites applications qui évitent de toucher aux fichiers de configuration. Il y a aussi l'exclusion par défaut des paquets de développement qui permettent de réduire la place occupée par l'OS de manière non négligable. Mais, je me rend compte que Fedora contient beaucoup moins de packages que n'avais ArchLinux.
Peu importe me dis-je, je vais faire des paquets RPM ... Et je cherche sur le web comment faire des spec file et comment les transformer en paquets RPM. Ce n'est pas forcément plus compliqué mais il y a certaines différences:
- il est très facile de faire des fichiers spec qui s'installent sur le système. Il faut faire attention à bien définir BuildRoot.
- les sources ne se téléchargent pas toute seules
- comment faire des spec file qui téléchargent de repositories svn ??? je ne sais pas
- pas d'outil comme yaourt qui permet d'installer facilement plein de spec files à la fois
- pas de repository de spec file où on pourrait partager.
Pour toutes ces raisons, je trouve la vie difficile avec Fedora, même si cette distribution a de nombreux avantages, j'envisage de revenir à ArchLinux ... Mais j'aimerais bien rester avec Fedora.
Tout le but de mon long discours, c'était pour proposer une nouvelle manière de voir le problème de l'installation des logiciels sous GNU/Linux. A mon avis, toutes les distributions gagneraient à intégrer un système comme AUR ou n'importe quel utilisateur peut proposer un script pour compiler automatiquement un paquet qui ne serait pas fourni de base. Un peu comme gentoo, mais avec les paquets binaires en plus.
Vous avez des remarques à faire ...? Des suggestions sur les endroits où je pourrais poster mes idées ?
Mildred
> Lire le journal (79 commentaires, moyenne: 2,4).
Compatibilité
En gros ce que tu demandes c'est que chaque distros maintienne un "dépôt" officiel pour les programmes non-inclus, avec potentiellement pas mal de paquets/scripts faits à la va vite, compatibles avec seulement une distro, voire une seule version/une seule architecture.
Une distro voulant se vanter d'une certaine stabilité risque de ne pas être enchantée à cette idée, d'autres ont déjà un système du genre, cherchant plutôt l'équilibre entre la bidouille et le paquet officiel : les dépôts du type contrib ou universe. Au final on arrive toujours à la même chose.
Que ce soient les pkgbuilds, les slackbuilds ou tout autre système du même genre, on ne contribue qu'à une seule distribution. Il suffit d'en changer pour se retaper le script/paquet des programmes qui ne sont pas dans le dépôt officiel.
La solution que j'aime bien, et que tu cites, c'est Zero Install. Il est relativement simple de faire une interface (pour un binaire et/ou une source à compiler), c'est indépendant de la distro, c'est simple à utiliser, c'est sécurisé, on peut regarder dans les logiciels installés par la distro pour éviter de télécharger des dépendances inutiles, on peut installer plusieurs versions d'un même programme, etc etc
Personnellement je trouve ça idéal pour distribuer les logiciels tiers dont tu parles. Ça gagne vraiment à être utilisé et bidouillé, et je cherche encore les inconvénients sur le fond. On peut même spécifier plusieurs SE dans une interface (une version Linux x86, Linux x86-64 et FreeBSD x86 dans la même interface par exemple).
Persiste.
Re:
Perso, je trouve tout cela un peu confu. Tu dois avoir un (ou plusieurs) problème bien spécifique et du fait des plans "délirants".
Oui, on peut faire des fichiers spec qui vont récupérer les sources sur le web ou dans svn, etc...
Oui, il y a des dépôts qui existent avec ça.
Mais, ce n'est pas dans la philosophie de Fedora. Donc c'est peut-être moins bien que ArchLinux (que je ne connais pas).
De plus, il y a souvent des problèmes légaux (pas seulement des problèmes de brevets).
Bref, techniquement il n'y a pas de problème. Mais comme je n'utilise pas, je ne peux pas en dire plus.
Donc dit précisément ce que tu veux (par exemple "je veux installer bidule"), et si quelqu'un connait l'existance d'un paque rpm ou d'un dépôt il te l'indiquera.
En passant, pose ta question sur http://www.fedora-fr.org/ . Tu auras plus de chance d'avoir une réponse satisfaisante.
Lis la FedoraFaq non officielle : http://www.fedorafaq.org/
Il y a de nombreux dépôts Fedora :
http://rpm.livna.org/
http://freshrpms.net/
http://dag.wieers.com/
http://atrpms.net/
http://newrpms.sunsite.dk/
http://dribble.org.uk/
NB : livna, freshrpms et dribble font fusionner :
http://rpm.rpmfusion.org/
ATTENTION : Les dépôts sont parfois d'une qualité variable et souvent compatibles entre eux.
Donc si tu mélanges des dépôts et que ça sucks, ne soit étonné. Tu auras été prévenu.
-
[^]Re: Re:
Posté par Olivier Serve (Jabber id, page perso, ) le 10/12/2007 à 11:26. (lien). Évalué à 5.ATTENTION : Les dépôts sont parfois d'une qualité variable et souvent compatibles entre eux.
Donc si tu mélanges des dépôts et que ça sucks, ne soit étonné. Tu auras été prévenu.
Autrement dit, Fedora sucks by design. Merci de l'avoir dit aussi clairement.-
[^]Re: Re:
Posté par Jean-Philippe Garcia Ballester (Jabber id, page perso, ) le 10/12/2007 à 11:28. (lien). Évalué à 2.Comme une majorité des distributions linux...
-
[^]Re: Re:
Posté par liberforce (Jabber id, page perso, ) le 10/12/2007 à 12:51. (lien). Évalué à 3.Tout à fait. J'avais particulièrement apprécié à ce sujet ce billet d'Adam Williamson de Mandriva, sur les sources externes de paquetages: http://www.happyassassin.net/2007/10/24/mistakes/
-
-
[^]Attention au malentendu
Posté par Axel () le 10/12/2007 à 11:41. (lien). Évalué à 6.J'ajouterais à cela que l'auteur de ce journal est victime d'un effroyable malentendu au sujet de Fedora, et je pense qu'il est de mon devoir de lui dire la vérité.
Au cas où tu ne l'aurais pas deviné, Fedora n'est pas une distribution Linux ! Et non, Fedora n'est qu'une vitrine technologique pour Redhat, et ne vise pas du tout à fournir des logiciels ni à Mme Michu, ni au premier hacker venu qui voudrait développer ou créer des paquets de ses logiciels favoris.
Les plus affutés d'entre vous auront compris que tout ceci ce n'est qu'une version hypocrite et de mauvaise foi des bons vieux DIY & RTFM.
J'imagine ton immense déception, mais c'est hélas la stricte propagande que certains aiment à utiliser pour contrer les critiques vérité.-
[^]Re: Attention au malentendu
Posté par GeneralZod () le 10/12/2007 à 11:49. (lien). Évalué à 1.sed 's/Redhat/communauté/'
Même si ça manque de ";-)", "Pierre Tramo j2ee Architecte", je suppose que le reste est une forme d'humour.-
[^]Re: Attention au malentendu
-
-
[^]Re: Attention au malentendu
-
-
[^]Re: Re:
Posté par GeneralZod () le 10/12/2007 à 12:17. (lien). Évalué à 3.Parce que Fedora est responsable du contenu des dépôts tiers ?
Hein, des dépôts tiers incompatibles entre eux, c'est un peu le lot de la plupart des distributions ... Par contre, ça commence à se décanter du côté de Fedora.-
[^]Re: Re:
Posté par Olivier Serve (Jabber id, page perso, ) le 11/12/2007 à 10:59. (lien). Évalué à 0.Parce que Fedora est responsable du contenu des dépôts tiers ?
Non, mais Fedora et les autres distribs ne proposent rien pour éviter ça.-
[^]Re: Dépôts tiers
Posté par ZeBob (Jabber id, ) le 11/12/2007 à 15:16. (lien). Évalué à 2.Tu veux qu'ils proposent quoi ? C'est une réaction normale de certains utilisateurs qui veulent des trucs pas libres/plus récents. Pour moi le problème se situe au niveau de l'utilisateur qui ne sait pas attendre six mois une nouvelle version.
La seule chose que les distros pourraient faire, c'est d'encourager la création d'écoles/de guide d'empaquatages afin de former des mainteneurs motivés pour le cas des logiciels non-empaquetés.-
[^]Re: Dépôts tiers
Posté par GeneralZod () le 11/12/2007 à 16:13. (lien). Évalué à 4.En tant que membre de l'association Fedora-FR, je tiens à souligner que notre projet de documentation contient quelques tutoriels concernant la création de paquets. Le chan #fedora-devel-fr (freenode) a été créé dans l'intention d'aider les nouveaux contributeurs à rejoindre le projet en tant qu'empaqueteur, traducteur. etc...
Il y a quelques empaqueteurs francophones de Fedora (et des bons, pas des charlots) mais également EPEL, Livna qui trainent sur ce chan et qui seront ravis de vous aider, faire des revues de paquets et vous sponsoriser.
-
-
-
-
-
[^]Re: Re:
Posté par Mildred (Jabber id, page perso, ) le 10/12/2007 à 19:20. (lien). Évalué à 1.En gros si un programme n'exise pas dans Fedora, alors je dois chercher un dépot externe qui le fournit (si toutefois il en existe un).
Et qi je veux deux programmes qui sont dans deux déps différents incompatibles, alors je peux essayer (et je le ferais probablement, par faute d'autre alternative) et ça risque de mal marcher.
Dernière solution, faire ses propres paquets ... mais comme ce n'est pas immediat (surtout avec rpm) même si ce n'est pas difficile, j'aimerais bien partager mon travail avec d'autres. C'est un peu ça mon idée. Mais comme je n'ai ni l'envie, ni l'énergie de maintenir un dépôt à moi, je ne le ferais probablement pas :( domage.
Ou alors, trouver un moyen de partager les fichiers spec ...
Et le problème c'est que j'ai très souvent des programmes que je veux utiliser non packagés, juste quelques exemples:
- gspaceui
- wmctrl
- gtkradiant
- python-urwid
- bzr-svn
- aiccu
- aptoncd
...-
[^]Re: Re:
Posté par baud123 (Jabber id, page perso, ) le 10/12/2007 à 19:37. (lien). Évalué à 2.En gros si un programme n'exise pas dans Fedora, alors je dois chercher un dépot externe qui le fournit (si toutefois il en existe un).
euh non, hormis pour les gros dépôts "officiels"
mieux vaut rebuilder un rpm si tu en as vraiment besoin pour ta version de distrib'. À partir du src.rpm c'est encore moins compliqué que de repartir de zéro.
Bon après si tu veux pourrir ta base de gestion de version avec 15000 dépôts plus hétéroclites et incompatibles entre eux les uns que les autres, cela te regarde...
Pour les paquets que tu ne trouves pas, dès lors qu'ils sont libres tu peux les suggérer en terme de paquets à réaliser, comme cela ils seront intégrés upstream et tout le monde en bénéficiera (à quoi bon bosser dans son coin ?). S'ils ne sont pas libres, mieux vaut investir sur des équivalents libres... cela sera plus pérenne.-
[^]Re: Re:
Posté par Mildred (Jabber id, page perso, ) le 11/12/2007 à 00:27. (lien). Évalué à 1.Et en attendant leur intégration, je fais quoi ?
Il y a aussi des programmes qui n'ont peut être pas beaucoup de chance d'être intégrés ... tellement ils sont lourds. Delta3D [http://www.delta3d.org/] par exemple ... enfin je n'ai pas demandé-
[^]Re: Re:
Posté par IsNotGood () le 11/12/2007 à 04:14. (lien). Évalué à 4.> Et en attendant leur intégration, je fais quoi ?
Ben tu le fais.
Si t'exiges aux autres de le faire, alors on peut t'exiger de le faire.-
[^]Re: Re:
Posté par Gniarf () le 11/12/2007 à 10:23. (lien). Évalué à 2.ou tu payes des gens pour le faire. pas forcément des cents et des milles, hein, le troc et les systèmes de primes offertes ("bounties") ca marche aussi.
maintenant, rester dans un rôle de consommateur passif à attendre en râlant que ça soit intégré sans vouloir s'impliquer ou contribuer... parait que c'est pas toujours efficace.--
Windows has no users. It has hostages.
-
-
-
-
[^]Re: Re:
Posté par IsNotGood () le 10/12/2007 à 22:22. (lien). Évalué à 1.> En gros si un programme n'exise pas dans Fedora, alors je dois chercher un dépot externe qui le fournit (si toutefois il en existe un).
En gros c'est l'idée pour un utilisateur "normal". Pour un utilisateur "pointu", il peut faire son/ses paquet(s). J'ai deux ou trois paquets "perso".
> Et qi je veux deux programmes qui sont dans deux déps différents incompatibles, alors je peux essayer (et je le ferais probablement, par faute d'autre alternative) et ça risque de mal marcher.
Pas forcément. Individuellement les paquets sont rarement incompatibles.
Ce que tu peux faire, c'est réaliser ton propre dépôt avec des paquets copiés de divers dépôts. Createrepo (du paquet createrepo) te permet de faire un dépôt les doigts dans le nez. C'est juste une commande à lancer puis il faut ajouter le dépôt nouvellement créé à la configuration de yum. Et voilà.
> - wmctrl
C'est dans Fedora (trouvé en faisant "yum search").
> - aiccu
C'est dans Fedora.
> Ou alors, trouver un moyen de partager les fichiers spec ...
C'est ce que fait Fedora (mais n'autorise que ce qui est libre) :
http://fedoraproject.org/wiki/PackageMaintainers/Join
Tu trouveras dans le cvs plein d'exemples de fichiers spec :
http://cvs.fedoraproject.org/viewcvs/-
[^]Re: Re:
Posté par Mildred (Jabber id, page perso, ) le 11/12/2007 à 00:27. (lien). Évalué à 1.effectivement, certains de mes exemples y sont ... c'est parce que 'yum search' était un peu long. C'était des paquets qui me manquaient sous ArchLinux.
-
-
[^]Re: Re:
Posté par IsNotGood () le 10/12/2007 à 22:30. (lien). Évalué à 1.> - gtkradiant
http://lepouf.free.fr/downloads/Radiant/
-
[^]Re: Re:
Posté par GeneralZod () le 11/12/2007 à 12:02. (lien). Évalué à 2.Je t'invite cordialement à rejoindre la grande famille des empaqueteurs Fedora ou à rajouter les paquets dans la wishlist.
Je note que aptoncd peut être avantageusement remplacé par yum dans Fedora.-
[^]Re: Re:
Posté par Mildred (Jabber id, page perso, ) le 11/12/2007 à 14:18. (lien). Évalué à 0.L'avantage de aptonce, c'est que tu peux élécharger des paquets ubuntu et les graver sur un CD pour aider quelqu'un aui a ubuntu mais pas de connexion internet ...
Je doute que yum puisse télécharger des paquets ubuntu, si ?-
[^]Re: Re:
Posté par GeneralZod () le 11/12/2007 à 14:54. (lien). Évalué à 1.Et quel est le rapport avec Fedora ?
-
[^]Re: Re:
Posté par IsNotGood () le 11/12/2007 à 20:02. (lien). Évalué à 0.> L'avantage de aptonce, c'est que tu peux élécharger des paquets ubuntu
L'avantage de Yum c'est que tu peux le faire pour Fedora :-)
Passons.
Tu devrais peut-être regarder pour utiliser la virtualisation de Fedora. Par défaut F8 utilise KVM (c'est activé dans le noyau par défaut) et il te faudra un cpu supportant VT. Sinon il faut installer kernel-xen et que Ubuntu supporte Xen.
NB: Xen est actuellement plus évoluer mais Fedora va l'abandonner petit à petit au profit de KVM/Qemu.
Cette page devrait t'aider :
http://fedoraproject.org/wiki/Docs/Fedora8VirtQuickStart
-
-
-
universe et PPA
Salut,
Ubuntu bosse sur le problème de la disponibilité des applications depuis ses débuts. Universe et PPA sont les deux solutions trouvé. Universe est très bien intégré, mais pas PPA, et c'est bien dommage. Il faudrait pouvoir faciliter le regroupement des PPA, etc. PPA est prévu pour construire aussi des RPM. SuSE a aussi sa ferme de compilation de paquet publique.
Cordialement,
Étienne, qui vient d'envoyer un nouveau paquet dans sa PPA.
E Ultreïa !
-
[^]Re: universe et PPA
-
[^]Re: universe et PPA
Posté par Gniarf () le 10/12/2007 à 14:46. (lien). Évalué à 2.si c'est pas rationnalisé un minimum, ça ira pour un ou deux softs tiers, guère plus :
http://www.happyassassin.net/2007/10/24/mistakes/--
Windows has no users. It has hostages.-
[^]Re: universe et PPA
Posté par Étienne Bersac (Jabber id, page perso, ) le 11/12/2007 à 20:09. (lien). Évalué à 1.Ce billet est un brûlot cynique et trop long. Ubuntu facilite les PPA, mais fournit aussi Universe ; ce qui change complètement la donne par rapport à Mandrake en 2000 - 2004. De plus, il confond le problème des dépôts incompatible avec le manque d'outils de résolution de dépendances.
Les paquets des PPA sont compilé avec l'archive globale. Faut vraiment le vouloir pour installer un bibliothèque d'un PPA qui va casser un logiciel d'une autre archive. La encore on revient à la qualité de l'empaqueteur : est-ce quest les dépendances sont suffisament restrictives ? Si je compile pour un paquet pour hardy, il ne s'installera pas sur gutsy : la libc n'est pas la même ! (merci debhelper)
Bref, la démocratisation des logiciels est un vrai problème, et télécharger.com n'est pas la solution qui va au monde libre pas plus que la fouilli des rpmfind, apt-get.org et consorts. Universe et PPA sont *une* bonne solution qui mérite d'être amélioré.
On en reparlera quand Ubuntu sera devenu un cauchemard de dépendances.--
E Ultreïa !
-
checkinstall
je suis assez d'accord avec toi sur le principe. Le système archlinux me semble vraiment intéressant, je n'ai pas encore testé mais cela me tente bien.
Pour une installation rapide à partir des sources, s'intégrant pas trop mal à la distribution (permet de retirer facilement le programme par la suite), il y a checkinstall que tu connais peut-être. Le soucis c'est qu'il ne gère pas les dépendances, et que sur certains programmes le paquet ne se fait pas toujours (parfois c'est facile à corriger, parfois pas).
L'avantage c'est que c'est aussi rapide à faire que de taper un "make install" (make checkinstall à la place, bon 5 lettres de plus seulement).
Mais cette multiplicité des paquets, cette redondance de travail "pour rien", sont un problème.
J'avais soumis quelques questions à l'époque :
http://linuxfr.org/~farvardin/22989.html
On m'avait dit que chaque distribution avait des versions trop différentes pour pouvoir s'entendre.
Et bien justement, ne serait-il pas possible de s'entendre pour des bases stables, redéfinies à intervalle régulier, sur lesquels ces paquets pourraient être bâtis ? Dire, par exemple on bloque sur la libc 2.7, sur xorg 7.3 etc
You can't grep dead trees...
-
[^]Re: checkinstall
Posté par baud123 (Jabber id, page perso, ) le 10/12/2007 à 09:25. (lien). Évalué à 3.Dire, par exemple on bloque sur la libc 2.7, sur xorg 7.3 etc
ce que propose Linux_Standard_Base (LSB) par exemple ?
à qui cela sert-il hormis aux softs proprios ?
faire un paquet ne prend pas réellement de temps pour celui qui y est habitué, le tester en revanche...-
[^]Re: checkinstall
Posté par Farvardin (page perso, ) le 10/12/2007 à 10:59. (lien). Évalué à 1.faire un paquet ne prend pas réellement de temps pour celui qui y est habitué,
oui, sauf que l'on se retrouve avec des distributions qui ont bcp de paquets disponibles (genre Debian), et d'autres où c'est la misère (genre opensuse, mais là aussi il semble que c'est en train de changer et de s'améliorer). C'est quand même du temps de perdu que d'avoir tous ces efforts pour seulement une distribution alors que toutes pourraient en bénéficier.
le tester en revanche...
justement, un seul format de paquet permettrait d'avoir plus de testeurs, ceux de chaque distribution.
à qui cela sert-il hormis aux softs proprios ?
cela pourrait servir à tout le monde, en mettant toutes les distributions sur un pied d'égalité au niveau des logiciels disponibles.
De plus, il faudrait standardiser les noms des dépendances. Pourquoi c'est machin-dev sous debian, machin-devel sous suse ?
Standardiser également les emplacements des fichiers. Pourquoi on a /usr/games/nethack ? C'est pas assez sérieux pour mettre dans /usr/bin ? Pourquoi pas faire un /usr/toys/xeyes tant que l'on y est (il est dans /usr/bin d'ailleurs), ou un /usr/network/firefox un /usr/graphics/gimp etc ? Cela pourrait apporter encore plus de confusion et différence d'interprétation, qui semblent si chers aux développeurs linux :)--
You can't grep dead trees...-
[^]Re: checkinstall
Posté par zul (Jabber id, page perso, ) le 10/12/2007 à 11:16. (lien). Évalué à 2.> Pourquoi on a /usr/games/nethack ?
Parce qu'a l'origine, tout le monde n'avait pas le droit de jouer :D
Voir man hier(8) sur une BSD et le group games :).
Rien à voir avec les dev linux donc. Ca existe depuis l'origine d'Unix.
-
-
[^]Re: checkinstall
Posté par Gniarf () le 10/12/2007 à 13:55. (lien). Évalué à 2.ouais \o/ la LSB, avec ses 53 versions et variantes soit déjà presque autant que de versions d'une distribution classique, et puis ses 3-4 modules (Core, C++, Desktop...) histoire d'égaler les versions Discovery, Destkop, Corporate, Server... ah, et j'oubliais, on ajoute encore une dimension parce qu'on s'ennuyait : par architecture matérielle.
oui, c'est sûr, un tit logo "Linux Standard Base" ca fera bien sur l'emballage...--
Windows has no users. It has hostages.-
[^]Re: checkinstall
Posté par baud123 (Jabber id, page perso, ) le 10/12/2007 à 14:40. (lien). Évalué à 2.ouais, bah ça :-)
ils ont au moins le mérite de proposer une réponse à ceux qui prônent le yakafokon et - clairement - cela montre que ce n'est pas simple (hormis tout figer dans le temps ou tout avoir en libre, ce qui évite en partie la majeure partie des soucis).
-
-
-
[^]Re: checkinstall
Posté par Mildred (Jabber id, page perso, ) le 10/12/2007 à 19:20. (lien). Évalué à 1.Je ne connais pas checkinstall, mais à priori, je n'aime pas trop cette solution. Surtout car je n'ai aucune maîtrise de ce qui se passe.
Si je fais un make DESTDIR= install, je sais exactement où vont aller les fichiers installés ... le checkinstall reste flou. Sans compter nombre de projets (sont tout mes projets) qui n'utilisent pas de Makefiles mais d'autres systèmes comme un simple script bash, jam, (s)cons, cmake, ...
Pour moi c'est autant un hack que le make install dans /usr/local ... un peu plus maintenable, c'est vrai, mais pas la bonne solution.-
[^]Re: checkinstall
Posté par morphalus (page perso, ) le 10/12/2007 à 21:43. (lien). Évalué à 2.
Pour moi c'est autant un hack que le make install dans /usr/local ... un peu plus maintenable, c'est vrai, mais pas la bonne solution.
Tiens, FreeBSD et son système de ports qui installe tous les logiciels tiers dans /usr/local est en fait un hack géant ? ...-
[^]Re: checkinstall
Posté par Mildred (Jabber id, page perso, ) le 11/12/2007 à 00:32. (lien). Évalué à 2.Il faut comprendre ce que je dis ... Si je dis un make install dans /usr/local, ca veut dire que je télécharge les sources dans /usr/src, je fait un tar xvf et make install sans rien d'autre.
J'ose espérer que FreeBSD, lorsqu'il installe un port (et peu importe où il l'installe) enregistre quels fichiers il a installé, et que ces fichiers appartiennent bien au port installé.-
[^]Re: checkinstall
Posté par morphalus (page perso, ) le 11/12/2007 à 21:07. (lien). Évalué à 1.Ah oki, je vois ce que tu veux dire, désolé.
-
-
-
[+] Historique
Depuis que je traine sur linux (a peu pres 6 ans), je me suis toujours demande pourquoi on crie qu'il faut des standards et que l'on se traine deux systèmes de fichiers (rpm et deb) et que chaque paquet a un peu de mal si on le change de distrib pour 0laquelle il est prévu.
Si on unifiait déjà ça, ça permettrait aux éditeurs de logiciel de n'avoir qu'un "installeur" linux a créer, moins de compétence a avoir, plus de temps, il n'y aura un seul .deb et tout le monde pourrait l'utiliser.
-
[^]Re: Historique
Posté par José JORGE (Jabber id, page perso, ) le 10/12/2007 à 08:41. (lien). Évalué à 6.Cf. La cathédrale et le Bazar. S'il y a encore 3 paquets majeurs RPM et DEB, c'est parce qu'aucun des 2 n'est clairement supérieur à l'autre, mais chacun est suffisament différent pour séduire des utilisateurs différents. Demande-toi pourquoi un habitué de Debian prend Ubuntu comme desktop : parce qu'il aime les paquets DEB.
Il faut savoir que vu la spécificité des compilations sous chaque distribution (choix d'optimisation, etc.) les paquets qu'elles font ne marchent pas souvent sur une autre distribution.
Il est par contre très simple de faire un paquet qui fonctionne partout (cf. logiciels propriétaires : Flash, RealPlayer n'ont qu'un seul binaire qui marche partout). Par contre ces binaires sont forcément plsu gros (ils intègrent les librairies (compilation statique) pour être sûr de ne pas manquer de quelque chose.
Mais alors, pourquoi depuis 6 ans ce n'est pas plus courant? Parce qu'il est moins fatiguant de faire {urpmi yum apt-get install} firefox que d'aller chercher sur le site de Mozilla le binaire. Les gros projets le font quand même (OOo). Je me souviens que Gcompris était fourni en RPM jusqu'à ce que son développeur se fatigue de le préparer.
Bref, ce qu'il manque, c'est des mimines qui ont envie de faire des RPM universels - RPM est exigé par la LSB depuis longtemps.
A nous les libristes de nous y mettre.-
[^]Re: Historique
Posté par Farvardin (page perso, ) le 10/12/2007 à 09:21. (lien). Évalué à 6.aucun des 2 n'est meilleur, c'est possible, mais vu comment c'était long et peu réactif pour installer un paquet sous opensuse (il parait que cela s'est amélioré depuis), je suis vite retourné à Debian vu la galère que c'était.
ps : un véritable habitué de Debian reste à Debian sur le "desktop", pas besoin d'Ubuntu ;)--
You can't grep dead trees...
-
[^]Re: Historique
Posté par baud123 (Jabber id, page perso, ) le 10/12/2007 à 09:22. (lien). Évalué à 1.Flash, RealPlayer n'ont qu'un seul binaire qui marche partout)
ah sur ppc et x86_64 aussi ? on m'aurait menti ? :D-
[^]Re: Historique
-
-
[^]Re: Historique
Posté par Mildred (Jabber id, page perso, ) le 10/12/2007 à 19:20. (lien). Évalué à 1.Pour illustrer ton propos, je rajouterais je ne n'aime pas du tout deb, alors que rpm (si on développe des outils appropriés) est beaucoup mieux. En gros je n'aime pas la manière dont les paquets deb sont créés (il faut modifier le tarball source, et de un, et créer un makefile pour dire comment compiler, et de deux).
Donc non.
Avec RPM, tu as un fichier spec, qui te donne l'URL du paquet (encore faut il développer un soft pour le télécharger, actuellement, c'est fait à la main), qui te dis comment le décompresser, le compiler, et l'installer adns un faux dossier racile qu'on peut ensuite packager. (un peu comme les PKGBUILD d'Arch en plus puissant (sur certains aspects) et plus compliqué)
-
-
[^]Re: Historique
Posté par Misc (page perso, ) le 10/12/2007 à 09:54. (lien). Évalué à 10.Je doit reconnaitre que je suis assez étonné de voir que depuis le temps, il y a encore des gens qui se disent que la seul différence entre 2 distros, c'est le format de paquets. Il faut bien se rendre compte que le format n'est qu'une goutte d'eau par rapport au reste.
Parmi les problémes, il y a les versions de logiciels, les noms des libs, la politique d'intégration ( menu, systéme de démarrage, etc ).
Au nom de la compatibilité avec les autres pour le monde commercial, on devrait interdire à Canonical de pousser Upstart ? À Fedora de mettre un perl plus récent ( genre 5.10 ) non compatible binairement avec le 5.8 ? À Mandriva de compiler kde avec l'option -fvisiblity ?
Le monde du libre vit grace à son bordel et la liberté qui l'engendre. Il y a rien qui incite vraiment à garder la compatiblité, rien dans le sens ou une distro qui ferait ça n'aurais pas d'avantage si visible que ça face aux autres. Ça passerais si le monde du libre n'était pas si fertile mais c'est pas vraiment le cas.-
[^]Re: Historique
Posté par Mildred (Jabber id, page perso, ) le 10/12/2007 à 19:25. (lien). Évalué à 2.C'est bien pour ça que chaque distribution a besoin de compiler les paquets différamment ... Et c'est pour ça qu'il faut partager ce travail au maximum et le rendre facile (car tous les paquets sur toutes les distributions, ça fait beaucoup de travail.)
Si chacun s'y met, et crée des fichiers spec pour les paquets qu'il aime, et partage son travail avec les autres, d'un coup il y a moins de travail à fournir globalement et individuellement (on profite de ce que les autres ont partagé).
-
pkgsrc
Si AUR ou pkgbuild sont liés à une distribution, tu peux essayer pkgsrc, pkgjam ou MacPorts qui sont des gestionnaires de paquets qui tournent (tourneront dans le cas de pkgjam) sur tout BSD, Linux, MacOSX. Les descriptions de paquets ne sont pas toujours simples (programmes qui ne comprennent pas DESTDIR, qui n'ont pas de configure ou dont le configure est foireux) mais au moins ça ne pourrira pas ton système vu qu'ils installent dans un dossier juste pour eux et sont capables de désinstaller exactement ce qu'ils ont installé.
Le problème, ils préfèreront installer leur propre perl, leur propre python, leurs propres dépendances plutôt que celui de ta distribution vu qu'il est coton d'installer des bibliothèques perl sans toucher aux dossiers où il est installé.
L'autre problème, il n'y a pas plus de paquets que dans debian, mais on peut mettre simplement en place des repositories (dans macports en tout cas) et donc on peut avoir des branches de paquets non testés.
-
[^]Re: pkgsrc
Posté par zul (Jabber id, page perso, ) le 10/12/2007 à 10:56. (lien). Évalué à 3.En parlant de pkgsrc, je pense qu'il faut parler de pkgsrc-wip qui permet à tout le monde (via un compte sourceforge) d'uploader dans un cvs ces différents packages et les partager (et peut-être même un jour les voir arriver dans l'arbre pkgsrc officiel.
Ca reste une approche classique (un dépôt géré par la communauté). Il est juste peut-etre plus simple (et mieux documenté, au moins par l'exemple) de faire des packages pour une 'distribution' source.-
[^]Re: pkgsrc
Posté par Mildred (Jabber id, page perso, ) le 10/12/2007 à 19:27. (lien). Évalué à 2.La distribution source est tentante, son immence problème c'est le manque de paquets binaires. Et comme je ne crois pas dans le dieu optimisation, et que je n'ai pas envie de transformer mon mac en grille pain, j'évite.
-
[^]Re: pkgsrc
Posté par Ernest H (Jabber id, ) le 10/12/2007 à 22:53. (lien). Évalué à 2.L'immense problème des paquets binaires, c'est que pour proposer un paquet, il faut le compiler sur toutes les architectures pour lesquelles ça doit marcher. Et à part pour debian qui est capable d'avoir des milliers de paquets sur plus de 10 architectures, c'est impossible à maintenir sérieusement. Cela dit, si tu as un i386, pkgsrc propose des paquets binaires et si c'est un ppc, il y a des paquets binaires pour certains programmes, mais pas tout.
-
[^]Re: pkgsrc
Posté par Mildred (Jabber id, page perso, ) le 11/12/2007 à 00:37. (lien). Évalué à 1.Si tu parles de Gentoo, ça me semble très limité, les paquets binaires. C'est pas vraiment prévu pour. Et la documentation à ce propos, il faut bien la chercher. Enfin si tu me dis que les paquets binaires Gentoo sont aussi bien que ceux de n'importe quelle distribution binaire.
Mais il me semble que quand j'avais regardé ce n'étais pas encore vraiment le cas.
Pour la compilation, bien sûr il faut des machines pour la faire au niveau de la distrib, mais il y a plein de petites distribs qui arrivent à s'en sortir ... et je ne pense pas que Gentoo soit une petite distrib. Et pas besoin de supporter les binaires sur s'importe quelle architecture si les ressources sont limitées.-
[^]Re: pkgsrc
Posté par Ernest H (Jabber id, ) le 11/12/2007 à 08:49. (lien). Évalué à 2.Non non, je parle de pkgsrc [http://pkgsrc.org], le système de paquets de NetBSD, qui marche sur à peu près n'importe quel machine faisant tourner n'importe quel système Linux ou Unix (et aussi les Mac OSX plus anciens).
http://www.netbsd.org/docs/pkgsrc/using.html#using-pkg pour savoir comment utiliser les paquets binaires dans pkgsrc.-
[^]Re: pkgsrc
Posté par zul (Jabber id, page perso, ) le 11/12/2007 à 09:56. (lien). Évalué à 2.D'autant qu'avec pbulk, il est trivial de regénérer un ensemble de paquet (voir tout pkgsrc) est de le diffuser pour un couple plateforme matériel / système d'exploitation. Par contre, il faut avoir du temps, beaucoup de temps voir pour certaines archis
(Sinon c'est aussi utilisé pour voir les regressions et les paquets qui compilent pas : voir http://mail-index.netbsd.org/pkgsrc-bulk/ pour l'ensemble des bulk générés et les rapports qui vont bien).
-
-
-
-
-
Today it sucks, tomorrow it won't
A ce propos, Ian Murdock a écrit 2 articles, en anglais:
http://ianmurdock.com/?p=388
http://ianmurdock.com/?p=391
Et la Linux Foundation a un wiki sur le sujet, en anglais aussi:
http://www.linux-foundation.org/en/Packaging/Wiki
-
[^]Re: Today it sucks, tomorrow it won't
Posté par farib () le 10/12/2007 à 19:00. (lien). Évalué à 3.Bon article.
Dommage qu'il faille s'appeller Ian Murdoch pour pouvoir reconnaitre des avantages de facilité à Windows par rapport à linux sans qu'on remette systématiquement en cause ta probité...-
[^]Re: Today it sucks, tomorrow it won't
Posté par Nicolas Schoonbroodt (Jabber id, page perso, ) le 10/12/2007 à 19:14. (lien). Évalué à 10.Extrait d'un mail que j'ai imprimé tout à l'heure pour mon cousin qui n'a pas internet. Il a un jeu acheté (pas une copie) qui ne marche plus sur son nouvel ordinateur (sous windows, le système facile)
Réponse : Nous vous invitons à suivre les instructions suivantes :
Même fédora et archlinux me semblent plus facile...
1- Installer le jeu sous Windows vista,
2- Faire un click droit sur le raccourci du jeu et cliquer sur la case, « Run as Adminstrator / Exécuter en tant qu'administrateur »,
3- Lancer le jeu et installer les pilotes Starforce comme demandé mais NE PAS redémarrer l'ordinateur,
4- Télécharger la mise à jour des pilotes de protection à l'adresse suivante : http://www.star-force.com/support/sfdrvup.zip ,
5- Décompresser le fichier SFDRVUP.ZIP et installer le fichier SFDRVUP.EXE pour mettre à jour les pilotes,
6- Redémarrer l'ordinateur,
7- Lancer le jeu.--
[ Répondre ] Ce commentaire est-il impertinent ou utile ?-
[^]Re: Today it sucks, tomorrow it won't
Posté par Farvardin (page perso, ) le 10/12/2007 à 22:26. (lien). Évalué à 4.très bon l'exemple :)
Ce genre de truc aussi c'est pas super convivial... (je n'indique pas cela juste parce que c'est un virus, mais parce que ce genre de manipulation me rebute plus que de patcher un noyau et le recompiler... et apparemment c'est le quotidien de bcp d'utilisateurs windows) :
http://www.infos-du-net.com/forum/62690-11-gros-virus
en ce qui concerne le texte de ian murdock sur l'installateur .exe qui facilite la vie sous windows (la première partie du moins, je n'ai pas lu le reste en détail), je trouve cela étonnant de la part de l'initiateur de Debian...
S'il y a qque chose que je trouve infiniment plus pratique sous linux, c'est bien la gestion des paquets. Cela doit être psychologique le côté "on va rechercher le logiciel avec un navigateur internet et on l'installe en cliquant dessus". À quand les fichiers .deb sur emule ou kazaa pour les rendre plus attractifs envers les "powerusers" windows ?
Je ne dis pas que le fait de pouvoir installer des paquets tiers autrement que par le gestionnaire de paquets est un mal, au contraire, et pas seulement pour des logiciels proprio, cela peut être de petits programmes non encore packagés officiellement. Mais cela ne devrait pas devenir un réflexe systématique ou la manière par défaut, plus un palliatif.--
You can't grep dead trees...-
[^]Re: Today it sucks, tomorrow it won't
Posté par farib () le 11/12/2007 à 01:37. (lien). Évalué à 0.je trouve cela étonnant de la part de l'initiateur de Debian....
Et re CQFD, le mec a pas tenu un propo "linux c'est génial, windows sapu" donc son propos n'est pas conforme à la ligne officielle qui consiste à refuser toute critique, donc c'est bizarre, forcément.
Le fond du propos de Ian Murchoch, c'est que même si le systeme Windows est développé de façon centralisé (c'est le cas de le dire puisqu'une seule et meme entité en est en charge) l'écosysteme de windows est développé de façon autonome et totalement décentralisé.
Et dans l'opensource, c'est l'inverse, alors que par essence, l'opensource c'était la décentralisation des développement, on observe que tout est en fait ultra-centralisé d'une part par le noyeau (intégration de ton module dans git ) et la distribution (intégration d'un logiciel dans les dépots). On est plus si libres que ça... cf le thread sur Apple qui dirige Webkit.-
[^]Re: Today it sucks, tomorrow it won't
Posté par Farvardin (page perso, ) le 11/12/2007 à 06:15. (lien). Évalué à 5.l'écosysteme de windows est développé de façon autonome et totalement décentralisé.
ouais, c'est tellement mieux comme conception... cet écosystème c'est quoi ? C'est les shareware à 2 balles codés en visual basic pour afficher les périphériques disponibles (que l'on a avec lspci sous le systère centralisé) ou lister les répertoires avec la taille des fichiers qu'il y a dedans (j'ai cherché longuement, mais pas pour chez moi bien sûr, un freeware décent qui fasse cela sous windows, alors qu'en ligne de commande ou avec kde c'était réglé). Ou alors les spyware ?
Ou encore ce pilote bluetooth, que m'a rapporté une connaissance, sur son beau windows vista tout frais, qui plantait la machine avec un bel écran bleu lors de chaque démarrage après son installation... bien entendu pas la faute à vista, la faute de l'écosystème qui contribue bénévolement à tous ces utilitaires indispensables...
Finalement, s'il doit y avoir une cathédrale et un bordel, Linux c'est la cathédrale, et windows le bordel. On me fera difficilement accepter que ce dernier représente une conception supérieure.
donc son propos n'est pas conforme à la ligne officielle qui consiste à refuser toute critique,
non pas forcément. Des critiques sur Linux et les LL, j'en lis tous les jours sur linuxfr, souvent à juste titre. Tiens il n'y a pas longtemps avec openoffice 2.3.0 lorsque l'on accédait à un fichier distant via samba sous linux, cela mettait ce fichier distant à 0, pas très sympa mais assez étonnant (vérifié sur 2 machines différentes), mais je n'ai même pas eu le temps d'en parler sur un forum OOo que c'était déjà corrigé avec la 2.3.1
Linux n'est certes pas parfait, mais ce n'est pas pour autant que reprendre ce qui fait tous les travers de windows (base de registres, une certaine conception anarchique de ergonomie cf vista) le rendra meilleurs.--
You can't grep dead trees...-
[^]Re: Today it sucks, tomorrow it won't
Posté par farib () le 11/12/2007 à 09:09. (lien). Évalué à 1.Tout va bien, ca prouve que tu n'as juste rien compris au propos de Ian Murdoch. Moinsse moi, ca te defoulera. Vive linuxfr.
-
[^]Re: Today it sucks, tomorrow it won't
Posté par Farvardin (page perso, ) le 11/12/2007 à 11:15. (lien). Évalué à 1.ben non tu vois, je ne t'ai pas "moinssé" sur ce coup-là, et je n'ai pas besoin de me défouler, je suis calme :)
Ensuite, par rapport aux propos de murdoch, ben oui, des fois cela ne se passe pas aussi facilement lorsque c'est packagé n'importe comment, mais d'un autre côté c'est pas la mer à boire de savoir installer un logiciel en ligne de commande lorsque cela n'a pas été correctement packagé.
Si le logiciel de sun avait été packagé avec autopackage, cela aurait été facile à installer. Évidemment c'est vers ce genre de facilité auquel il faut tendre, mais je ne vois pas en quoi windows avec ses installateurs .exe de m**** serait un modèle à ce niveau (là je commence à perdre mon calme effectivement). À mon avis au niveau de la facilité d'utilisation, le système de paquets sous mac os x est bien plus probant. Rien à installer, le paquet peut se déplacer d'une machine à l'autre tel quel, se lancer depuis n'importe quel disque dur etc--
You can't grep dead trees...-
[^]Re: Today it sucks, tomorrow it won't
Posté par farib () le 11/12/2007 à 12:10. (lien). Évalué à 2.Si le logiciel de sun avait été packagé avec autopackage, cela aurait été facile à installer. Évidemment c'est vers ce genre de facilité auquel il faut tendre, mais je ne vois pas en quoi windows avec ses installateurs .exe de m**** serait un modèle à ce niveau (là je commence à perdre mon calme effectivement). À mon avis au niveau de la facilité d'utilisation, le système de paquets sous mac os x est bien plus probant. Rien à installer, le paquet peut se déplacer d'une machine à l'autre tel quel, se lancer depuis n'importe quel disque dur etc
Je crois que tu passes a cote du probleme. Le probleme n'est pas d'avoir un systeme d'installation genial (RPM,DEB, MSI y arrivent tous tant bien que mal) mais d'avoir un point d'entree unique. Et c'est bien gentil de vouloir expliquer que les ISV sont mechant pas beaux avec leurs softs proprios tout pourri qui ont 15 ans d'age qui veulent pas utiliser autopackage, mais c'est la vie. Je me repete ( et je reprend les propos de Murdoch), meme avec autopackage, quel interet de supporter le libre avec ses 50 systemes de paquets different qui va te couter 50 equipes de packaging en plus pour augmenter ton marche de 0.3%.
Maintenant, c'est bien rigolo de vouloir comparer l'installeur Mac avec son OSX unique et sa 10aine de modele d'ordinateurs supportes avec la diversite des distributions linux et des architectures, et surtout, n'oublie pas de comparer aussi la part de marche de linux avec la part de marche des macs. Car avant de bouffer Windows, hein, il aura fallu bouffer Mac, et meme ca, c'est pas gagne.-
[^]Re: Today it sucks, tomorrow it won't
Posté par Farvardin (page perso, ) le 11/12/2007 à 14:02. (lien). Évalué à 1.meme avec autopackage, quel interet de supporter le libre avec ses 50 systemes de paquets different qui va te couter 50 equipes de packaging en plus pour augmenter ton marche de 0.3%.
pour les parts de marché, on verra comment cela va évoluer, mais à mon avis cela représente plus que 0.3 % d'augmentation. Pour le bureau, c'est encore un peu différent, mais là aussi cela va évoluer rapidement (oui je sais cela fait 10 ans que l'on dit cela...)
Il n'y a pas tant de systèmes de paquets que cela, 3 principaux, et encore on peut facilement installer une version à partir d'un paquet différent (sous opensuse j'ai déjà pu installer des rpm issus de fedora ou des deb, sous debian j'ai pu installer des rpm mandriva etc ok c'est pas très propre mais cela fonctionne), comme quoi il n'y a pas tant de différence que cela entre les distributions. À mon avis en respectant un peu plus les LSB on devrait arriver à qque chose de bien. Quand à réaliser un paquet autopackage (ou zero install etc), je ne pense pas que cela fasse un trop gros trou dans le budget des oracle et compagnie. Avec bcp moins de moyen planeshift arrive à nous sortir de très bon autopackage qui fonctionnent sur toutes les distributions à ma connaissance.
.de vouloir comparer l'installeur Mac avec son OSX unique et sa 10aine de modele d'ordinateurs supportes avec la diversite des distributions linux et des architectures,
Il y a quand même 2 architectures différentes, ppc et intel, et les développeurs arrivent bien à faire un paquet unique. OK, cela augmente la taille des paquets, mais cela fonctionne bien (si on fait abstraction tout de même de la frénésie d'Apple à "oublier" les anciennes version de son système dans la conception des nouvelles API). Le fait que les machines apple sont limitées en modèle est un faux pb, un logiciel qui tourne sur un "vrai" mac tournera sans doute pareil sur un pc normal bidouillé pour avoir mac os x.
Je pense que si on sort un paquet pour gcompris (je prends cet exemple car je sais que l'auteur est sensible à cette question des paquets), si cela sort pour PPC, i386 et x64, cela me semble bien suffisant, tant pis pour les "pauvres" admin de S/390 ou Sparc qui ne pourront pas faire jouer le petit dernier à gcompris sur le Mainframe de la société...
J'ai lu entièrement la seconde partie du texte de Murdock, mais il n'y a pas vraiment de proposition concrète ; "yakafokon fasse une API pour que les ISV puissent packager leurs applis.". L'idée est louable, mais cela reste encore bien vague...--
You can't grep dead trees...-
[^]Re: Today it sucks, tomorrow it won't
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 12/12/2007 à 00:02. (lien). Évalué à 3.Quand à réaliser un paquet autopackage (ou zero install etc), je ne pense pas que cela fasse un trop gros trou dans le budget des oracle et compagnie. Avec bcp moins de moyen planeshift arrive à nous sortir de très bon autopackage qui fonctionnent sur toutes les distributions à ma connaissance.
Oracle fournit un dépôt[1] non officiel pour Debian/Ubuntu pour Oracle Database XE.
Comme quoi, si les fournisseurs tiers daignaient enfin reconnaître les formats de paquets binaires des principales distributions. D'autant que ça ne demande pas énormément de ressources puisque certains bénévoles comme Dag Wiiers maintiennent des paquets RPM pour plusieurs distributions et plusieurs versions concurrentes de celles-ci sans trop de problèmes...
Il n'y aurait donc que deux formats principaux à fournir : pour passer d'une distribution à une autre, il faudrait juste adapter un minimum le paquet (avec des outils comme pbuilder[2] pour Debian/Ubuntu ou DAR[3] pour les RPM
[1]: http://www.oracle.com/technology/tech/linux/install/xe-on-ku(...)
[2]: http://doc.ubuntu-fr.org/pbuilder
[3]: http://dag.wieers.com/home-made/dar/
-
-
[^]Re: Today it sucks, tomorrow it won't
Posté par Gniarf () le 11/12/2007 à 21:36. (lien). Évalué à 2.arrete un peu. les ISV ils ont déjà un point d'entrée unique, il s'appelle Red Hat, et les autres distributions peuvent aller se faire cuire un oeuf.
et vu leurs tarifs, le coup d'une Red Hat c'est cadeau en général. et pour les crevards, il y aura CentOS et autres clones, le tout avec un petit clin d'oeil, ça leur suffira largement--
Windows has no users. It has hostages.
-
-
[^]Re: Today it sucks, tomorrow it won't
Posté par Mildred (Jabber id, page perso, ) le 11/12/2007 à 14:24. (lien). Évalué à 2.Euh ... Les paquets sous Mac OS X sont loins d'être les fichiers .dmg qu'on trouve sur le net avec un dossier .app dedans ... Un paquet Mas OS X te propose un petit assistant suivant-suivant-terminer comme sur Windows ou avec Autopackage et sert plutôt à installer des extensions au système (par exemple rEFIt, le support pour le système de fichier ext3, ...)
-
[^]Re: Today it sucks, tomorrow it won't
Posté par Farvardin (page perso, ) le 11/12/2007 à 16:19. (lien). Évalué à 2.oui, cela aussi ça existe. Si j'ai écrit "paquet", c'est pour éviter de dire "fichiers .dmg qu'on trouve sur le net avec un dossier .app dedans", le vrai nom je ne connais pas.
--
You can't grep dead trees...
-
-
-
-
[^]Re: Today it sucks, tomorrow it won't
Posté par Thomas Douillard () le 11/12/2007 à 09:47. (lien). Évalué à 3.Oui, mais non.
Pour un logiciel utile mais pas connu, utilisé par une communauté restreinte, mais utilisé, c'est pas forcément évident de le faire intégrer dans une distro, surtout si c'est récent, et que le logiciel en question ne concerne pas une population à tendance geekesque.
Bon, cela dit typiquement ce type de logiciel n'est pas forcément développé sous Linux ... bizarre ? Pas tant que ça peut être ...
Évidemment OOo est dans toutes les distros. C'est pas forcément le cas de logiciels moins gros ou moins connus.
-
-
-
-
[+] [^]Re: Today it sucks, tomorrow it won't
Posté par farib () le 11/12/2007 à 00:39. (lien). Évalué à -2.Voila, CQFD, qu'est-ce que je dis, paf, on carricature mes propos, et on prend bien l'exemple de la techno universellement reconnue comme pourrie pour les jeux (qui est très loin de représenter la majorité des jeux, heureusement).
Encore que la on est dans un cas ultra particulier avec les DRM/Anticopie de jeux vidéo ce qui est limite hors sujet avec lSV qu'évoquait Ian Murdoch, qui aux final doivent proposer 10 000 fois plus de progicels qu'il n'existe de jeux vidéos commerciaux.
-
-
[^]Re: Today it sucks, tomorrow it won't
Posté par Gniarf () le 11/12/2007 à 12:40. (lien). Évalué à 2.oui enfin, je cite : "let me first point out that our goal is to create a vibrant third party software ecosystem around Linux - you know, like the one Microsoft has built around Windows."
ils veulent faciliter l'installation et l'utilisation de logiciels commerciaux, enfin, propriétaires. disons par exemple, les jeux, des bidules comme Real Player ou Adobe Flash Player et divers softs proprio biens chers et bien spécialisés qui existaient sous divers Unix avant.
soit. c'est gentil de courtiser ces gens-là (et on pourrait rappeller le nouveau poste de Ian Murdoch, mais chut) mais ce n'est pas l'objectif poursuivi par un grand nombre des "contributeurs du libre" qui par conséquent se foutent de cette initiative qui ne résoud pas LEURS problèmes de libristes parce que pour eux ca ne change que le packaging et pas le fait que ça ne marche pas sur leur plateforme ou que le soft serait quand même mieux avec quelques menus en plus et quelques bidules en moins
inutile de venir râler si ce Flash Player n'est disponible que sur Intel 32 bits ensuite, par exemple. et une réponse du style "mais le Flash Player n'est déjà disponible que sur Intel 32 bits !" montrerait que tu n'as pas saisi la nuance.--
Windows has no users. It has hostages.-
[^]Re: Today it sucks, tomorrow it won't
Posté par IsNotGood () le 11/12/2007 à 13:36. (lien). Évalué à 1.Juste, mais....
Le "libriste" n'est souvent pas que dans la "mouvance" libre.
Il y a des libristes qui sont prêt à payer pour avoir un système qui a des contraintes qu'on trouve principalement dans le proprio (stabilité API/ABI, long support). Il y a des libristes qui utilisent par exemple Fedora pour leur activité 100 % libriste et RHEL (ou clone) pour leur serveur web, en entreprise, etc.
Le libre n'est plus un truc qui est uniquement développé en fonction de l'humeur des développeurs. Il rend des services, il a donc une certaine responsabilité.
Voir par exemple EPEL :
http://fedoraproject.org/wiki/EPEL
Mais tu as raison, dans les développeurs du libre c'est minoritaire.
-
[^]Re: Today it sucks, tomorrow it won't
Posté par letsyl () le 11/12/2007 à 13:43. (lien). Évalué à 3.Je te trouve un peu réducteur, ce problème n'est pas spécifique aux logiciels propriétaires (même s'il s'en trouve accentué).
Quand un logiciel libre n'est pas disponible pour sa distro favorite, il faut alors le compiler soi même. Cei n'est pas forcément trivial, surtout pour des utilisateurs débutants.
Exemple concret, mumble un (excellent) logiciel "à la" Teamspeak n'est pas dispo pour ma distrib et demande une version de la bibiothèque qt4 très récente. Au contraire, il existe un .exe tout simple pour les utilisateurs windows.
Evidemment les systèmes de gestion de paquets sont infiniments plus pratiques qu'un .exe, mais dans certains cas, il serait intéressant d'avoir un système qui permette d'utiliser un logiciel quelle que soit la distrib (peut être klik ?).-
[^]Re: Today it sucks, tomorrow it won't
Posté par Gniarf () le 11/12/2007 à 16:47. (lien). Évalué à 2.et demande une version de la bibiothèque qt4 très récente
euh là le coupable est facile à trouver :) tu cries au choix après ta distribution qui a osé ne pas fournir une bibliothèque sortie 2 mois après elle, ou après les développeurs qui ont choisi une bibliothèque pas encore présente dans les distributions couramment utilisées
d'ailleurs ils fournissent ce logiciel et pas une dépendance qui semble nécessaire mais impossible à satisfaire par la plupart des utilisateurs ? c'est un peu ballot, à se demander s'ils veulent qu'on utilise leur soft.
le fait qu'il existe sous windows sous forme d'un setup.exe est anecdotique : quelqu'un a fait le sale boulot de packaging, c'est tout, idem que si c'était sous OS X.--
Windows has no users. It has hostages.
-
-
[^]Re: Today it sucks, tomorrow it won't
Posté par Mildred (Jabber id, page perso, ) le 11/12/2007 à 14:28. (lien). Évalué à 1.Attention: third party software est différent de logiciel propriétaire !
Il y a plein de logiciels libres (bon, peut être pas tant que ça, mais un peu quand même) qui ne sont pas packagés, ou alors rarement. En particulier tout ce qui touche à la 3D j'ai remarqué, par exemple planeshift (sans l'artwork non libre), crystal space, ogre et les moteurs qui l'utilisent comme yake, delta3d et ses nombreuses dépendances.
Pouvoir les installer facilement serait une grande amélioration sur nos systèmes.-
[^]Re: Today it sucks, tomorrow it won't
Posté par Gniarf () le 11/12/2007 à 16:52. (lien). Évalué à 2.oh vraiment ? c'est le seul cas pertinent. le reste se trouve dans les sections non-free ou autre plf ou universe des distributions. et si ton soft libre-ou-presque n'y est pas, mets-toi au boulot, tout simplement
ce qui restera aura en général un vrai problème de license par rapport à la distribution concernée (comme Squeak)--
Windows has no users. It has hostages.
-
-
-
Stow c'est bon, mangez-en
GNU Stow helps the system administrator organise files under /usr/local/ by allowing each piece of software to be installed in its own tree under /usr/local/stow/, and then using symlinks to create the illusion that all the software is installed in the same place.
En français approximatif, ça donne:
GNU Stow aide l'administrateur système à organiser les fichiers dans /usr/local/ en permettant à chaque logiciel d'être installé dans sa propre arborescence dans /usr/local/stow/, et en utilisant des liens symboliques pour créer l'illusion que tous ces logiciels sont installés à la même place.
D'accord c'est pas un outil à mettre dans toutes les mains, mais c'est sympa pour installer des trucs pas standards...
Assez...
Il y en a assez de ces polémiques à propos des logiciels manquants dans telles ou telles distributions (Ubuntu, Debian, Fedora, Mandriva, même combat).
Pourquoi serait-ce donc la faute à la conception même des systèmes de paquets, aux cycles de publications des distributions ? Pour qu'un logiciel soit intégré à une distribution, il « suffit » de demander à ce qu'il le soit (RFP chez Debian) ou de proposer de le faire soi-même (ITP pour Debian).
Dès qu'on demande à ces messieurs (ceux-là même qui critiquent) de contribuer aux dites distributions avant de venir se plaindre, il n'y a plus personne. Ne leur viendraient-ils pas à l'esprit que, si certains logiciels ne sont pas disponibles dans telle ou telle autre distribution, c'était tout simplement parce que PERSONNE n'a daigné préparé un paquet binaire pour celle-ci, ou alors, sans jamais contribuer à cette dernière, en le gardant pour soi.
Or, si ces messieurs sont capables de compiler tant bien que mal (surtout quand on a connu ArchLinux...) ces logiciels dont ils ont tant besoin, pourquoi ne pas faire l'effort de proposer le résultat à tous, tout simplement, en respectant le format utilisé ?
Donc, non, Mildred (tu ne serais pas un second « ciol » ?), il n'est pas possible d'envisager de proposer AUR comme LA solution « idéale » pour installer des logiciels sous Linux, ne serait-ce parce que certaines distributions n'acceptent pas pour des raisons diverses et variées (sans doute futiles pour toi, comme la sécurité, la fiabilité, la stabilité, etc.). Imagine un instant qu'un esprit malicieux oserait publier un script dont le code consisterait simplement à effacer toute donnée dans les systèmes cibles ? Un script assez bien écrit toutefois pour que cela passe inaperçu (oui, cela serait également possible avec un dépôt non officiel pour Fedora, Debian, Ubuntu, ou autre sauf qu'il s'agirait précisément de dépôts non officiels). Il y a besoin d'un certain nombre de garde-fou pour que seules les personnes les plus motivées et compétentes puissent contribuer effectivement aux distributions actuelles. Entre proposer et maintenir un paquet, travail au combien ingrat s'il en est, il y a tout un monde.
Puisque vous semblez de plus en plus nombreux, mettez donc vos idées de développement en commun et proposez-nous quelque chose de construit la prochaine fois (une nouvelle distribution révolutionnaire en somme). En attendant, ce genre de débat stérile ne fait pas beaucoup avancer les choses.
Cette page a été générée par Templeet en 0.2502s (dont 0.0317 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.