Reprise du message précédent :
Bah en plus

je suis/reste attaché au concept libre de linux    

drapal

 
ça aurait pas été plus simple de juste installer chroot sur ton eeexubuntu (ça doit pas prendre des masses de place, ni pourrir ton install ), chrooter un environnement avec tout le paquetage de dev dessus, compile, passer le paquet sur l'install "originale" puis virer le chroot?

pourquoi pas mais, ce n'est pas le propos.  
va expliquer ça a un user normalement constitué...  
le pb c'est dans le fond. pourquoi faut il faire toutes ces manip; juste pour tester
un logiciel, alors qu'il pourrait être si simple de cliquer juste sur un executable cross_distrib.

ça on est d'accord
En ce moment je suis en train d'installer un programme scientifique (Wien2k) sur l'ordi à mon père et j'en pleure ... Le machin requiert 36 librairie, qui ne sont bien entendu pas packagées ... Par la suite on a le droit à des scripts shell qui contrôlent quand les lib sont mises dans des endroits non-standards (je tape des ln -s depuis 3 h)
 
bref vive la compilation quoi

 
humm, discuter d'un problème réel concernant la disponibilité des logiciels sous linux, pourquoi pas. Raconter n'importe quoi comme c'est le cas dans ce post. non.

LA solution c'est LSB et c'est vraiment LA solution...
 
http://www.linuxfoundation.org/col [...] groups/lsb
 
Bon appetit bien sur !

boarf , désolé c'était juste pour imager le fait que les logiciels linux s'adressent souvent/vraiment pour les dev. entre dev.
et que parfois cela ne sors pas de ce contexte. Evidemment, on peut citer
pleins d'autres contraires, dont le très bon ooo, gimp et bien d'autres utilitaires/logiciels extras
mais a mon niveau, la variabilité des WM et des libs ne m'incitent pas à me plonger
dans l'univers de la prog. linux.

 
Il n'y a pas tant de variabilité que ça en fait. Les grands bibliothèques (libc, libsdtc++, Xlib/xcb, Qt, glib, GTK+, freetype, cairo etc) sont très accrochés à la notion de compatibilité binaire et source. En clair, un soft compilé pour la libgtk 2.0 tourne encore aujourd'hui avec gtk 2.16 sans recompilation (modulo les éventuels bugs du programme mais c'est un autre problème).
 
Je parle même pas du noyau qui est ultra strict sur la compatibilité binaire et ne la casse jamais ou presque.

dans ce cas faut m'expliquer clairement ce qui empeche les developpeurs de diffuser
directement un binaire compilé executable+sources??

 
AMHA, vu que les distributions font ça très bien toutes seules, ils n'ont pas envie de se casser la tête à le faire. Certains le font OOo, firefox par ex.
 
mais en ciblant une version lsb  + les autres libs pas trop récente, généralement, ça marche plutôt bien.

Oui enfin OOo et mozilla, c'est des gros projets, ils ont des personnes pour faire que ça.
On rejoint la remarque de je ne sais plus qui :
Développer c'est un métier.
Packager en est un autre (et c'est aussi le cas sous les autres systèmes).
 
Et comme déjà répété X fois, la compilation statique ca existe, mais si ce n'est pas (rarement) utilisé c'est qu'il y a plein de bonnes raisons de ne pas le faire

 
je crois que les bons arguments sont posés +10^3
 

 
comme ca on n'additionne pas les bugs, on les partage

encore un exemple de difficulté
./configure
checking for stdint.h... yes
checking for unistd.h... yes
checking X11/Xlib.h usability... no
checking X11/Xlib.h presence... no
checking for X11/Xlib.h... no
configure: error: X Window System is required.
genre, X11 est déjà démarré  
je peux même pas faire un make du coup  
sur un autre pc, ce même logiciel compile et fonctionne  
ps : ce logiciel n'a même pas de GUI, uniquement en ligne de dommande.

Bah nan l'erreur c'est pas que t'as pas de serveur X, c'est que t'as pas les headers de developpement qui vont avec

 
Alors pourquoi as-t-il besoin des librairies X11 ?? Soit c'est mal fait, soit il genere des images/fichiers avec une librairie qui utilise X11...
 

 
Exactement... la compilation necessite simplement les librairies -dev quivontbieng   Cependant, pourquoi compiler ? Pas de package ? C'est plutot rare...

certes, j'ai trouvé un peu après avoir posté; mais je suis un power user  

c'est un serveur réseau souris/clavier donc il utilise X11

pas de package non; et ce n'est pas rare

Bah voilà

tu noteras que j'ai transféré l'executable+libs attachées d'un poste à l'autre (ubuntu==>mandriva) et ça a fonctionné;
ensuite je me suis cassé le trognon à ajouter les *-dev.rpm

Ce qui est vrais c'est la difficulté des doubles branches RH like et Debian like dans les distribs.
 
Ca serait pas mal qu'a terme on arrive à avoir au moins une seul architecture avec les libs au même endroit.
Ça simplifierait déjà nettement le boulot d'intégration qui est un peu sous évalué dans linux en général.
Le boulot de l'intégration pour fournir des packages stables est loin d'être négligeable et je suis a peut près certain que les devs comme les admins report sur l'autre les problèmes de compatibilité qui sont pour le moins pénible effectivement.
 
Je pense que les admins confirmeront qu'on reçoit souvent des trucs "pret à installer" ou au moins les 2/3 des dépendances manquent dans le doc par ce que les dev ne se sont même pas aperçu qu'ils les utilisaient ou qu'elles leurs paraissent "évidente".
 
C'est certain que le boulot est encore à faire avec ces logiciels, mais je pense que ce sont des modifications à intégrer dans les projets dés le départ pour qu'elles puissent réellement être suivies, par ce qu'une fois lancés ça n'est plus très compliqué de suivre les mises à jour.

make est une usine  gaz mais il existe d'autres systèmes de build ; avec make, tu fais TOUT.
il doit être possible de passer certaines options si le makefile le permet pour adapter les options de compilation
enfin, la dépendance à la compilation dont tu parles est normale.
Et pourquoi pas devenir packager ou proposer ces paquets ?

 
Par ce que c'est un métier à part entière et que c'est pas le mien   .
J'ai déjà suffisamment de mal à m'en sortir avec ce que je maitrise  

un exemple de facilité :
hier soir je cherche un logiciel me permettant d'acceder au sysFS de mon iphone via usb,
je fini par trouver itunnel (n'est pas dans les dépôts officiels) et il est livré avec les sources+binaire déjà compilé    
voilà enfin un exemple à suivre

 
nous sommes donc en désaccord sur ces deux points
 
1 - si c'était un taf a plein temps il n'y aurait vraiment pas autant de paquets dans l'archive debian
2 - le savoir est une arme, apprendre est une vertu imprescriptible plus tu sais, et plus tu es libre
 

C'est super crade de livrer des binaires déja fais, puisqu'au lieu de réutiliser les librairies proposées par la distrib, le binaire va posséder tous les librairies dont il a besoin, ce qui peut être énorme.  
Réutiliser les librairies du système, ca permet :  
- d'éviter d'avoir un binaire qui englobe des librairies avec plein de failles
- de gagner de la place
- et aussi un petit gain de perfs au niveau de la gestion mémoire je crois ..
 
Je conseille le blog de Flameeyes (développeur Gentoo) qui explique régulièrement ce genre de problèmes. Exemples :  
- http://blog.flameeyes.eu/2009/01/0 [...] insecurity  
- http://blog.flameeyes.eu/2009/03/2 [...] e-ancients  
- etc ...

je suis d'accord pour des logiciels "haut de gamme" (genre ooo où gimp...)
mia pour des p'tis utilitaires, je n'en vois pas l'intérêt. hors la majorité des logiciels non packagés ne sont pas pré-compilés.
le fait de pré-compilé avec les lib
 incluent evite au user de se tapper la logique du developpeur, cad d'la logique de "merde" (je suis dev. donc pas tappé ),
mais tous les jours je rale pasque les $users sont "cons"

tu peux livrer un binaire qui utilise des bibliothèques dynamiques, c'est pas interdit hein

Oui mais on revient au problème du fait pour l'utilisateur de devoir disposer des bonnes versions de ces bibliothèques

Ouai voila c'est quasi impossible de faire ca sous Linux.    
 
Les distribs proposent souvent des versions différentes de librairies, sans compter les patchs ajoutés par dessus. Ajouté à ca les gens qui ont des versions plus au moins à jour de leur distrib, et finalement c'est super compliqué de faire un binaire qui marche pour tout le monde.  

dans ce cas là il recompile pour son systeme.
mais cela n'empecherait pas de pré-compilé un binaire et de livrer aussi les sources, c'est ce que font les packager pour chaque distrib. il me semble.
pourquoi cette logique ne s'appliquerait elle pas au niveau même du developpeur.
il y a plusieurs cas :
1) les gros softs bien lourds : là bien sur, utilisé les libs au maximum et faire un suivi de packaging
pour chaque distrib. (en gros, rh like, debian)

2) les autres softs qui sont dispo. dans les repo, on en parle pas : c'est top

3) les p'tis softs variés et diverses venant de dev. indépendants du fin fond de la cabanelinux que l'on trouve en général sous forme de tar.gz (souvent sur SF)
ici, il faudrait proposé également le(s) binaire(s) déjà compilé : si ça fonctionne directement tant mieux non?
hors ce n'est quasiment jamais le cas (le binaire fourni).
primo : ça évite au user de se tapper une vérif des versions de lib.
deuzio : ça donne une image de facilité à linux (un peu comme windows et ses .exe que l'on peut DL un peu partout)

je ne saurais pas évaluer le ratio du çamarche/çamarchepaschezmoi   , mais j'ai remarqué
que certain prog. fonctionnent correctement même compilé depuis un autre systeme.

dans le cas où le binaire ne fonctionne pas ou pas bien, on voit à la fin si on peut compilé à partir
des sources fournies.

ouais alors plus simple... avoir une distribution qui a tous les paquets/softs même ceux qui ne marchent pas car plus maintenus. On pourrait même imaginer avec différentes versions plus ou moins récentes où l'utilisateur pourra choisir.
 
Bon reste plus qu'à inventer cette distribution.

Avec des distribs comme Debian ou Gentoo où le nombre de programmes proposés est tout simplement hallucinant, on n'a pas recourt à la compilation manuelle tous les jours quand même, si ?  
 
 

nan c'est vrai que niveau nombre de softs packagés c'est hallucinant
mais qd on s'interesse à des logiciels de niches... on commence a être limité
[mylife]
mais dernierement j'ai qd même pas mal compilé de softs tiers qui n'étaient pas dans les repositories
- freediag : c'est pour faire du diagnotique automobile par la prise obd
- remotepad : c'est pour utiliser mon iphone comme touchpad
- itunnel : pour acceder en ssh via usb de mon iphone jailbreaked
- g15tools : pour utiliser le lcd display de mes enceintes Z10 (bon après coup, je l'ai trouvé les plugins audacity en .deb )
[/mylife]

En même temps, tous les softs que tu cites se destinent très clairement à des bons gros geeks

pas forcément  
1- ça peut devenir lucratif et d'autre part : tous ces types de logiciels ne sont pas developpés sous linux.
2- oui ça c'est pour faire g33k  
3- c'est pour liberer mon "jouet" de l'emprise d'itunes+win32
4- logitech ne fournit pas "driver" pour utiliser ce lcd display

Ben le 1 et le 3, c'est clairement pas des logiciels grand public. Le grand public, qaund il a un problème avec sa VW, il va chez VW, et quand il a un iphone, il se contente d'iTunes.
 
edit: Je dirais même qu'heureusement il n'as pas accès à ce genre d'outils facilement, dans le premier cas, il peut abîmer son moteur, dans le deuxième, il peut briquer son iphone... Et dans les deux cas, la garantie saute.

  j'ai parlé de logiciel de niche (peu courants) un peu plus haut

qd on se lance dans l'experience obd diag auto, on lit beaucoup de documentation avant + pas mal d'autotest
[/HS]
ps : de même d'ailleurs pour l'iphone  
[//HS]

Le 4 aussi c'est quand même geek

bah non qd j'achete un produit, j'aime bien qu'il fonctionne jusqu'au bout : surtout sous linux.
ça faisait un p'ti moment que je lorgnais sur ces enceintes mais je les avait pas acheté car je savais pas si le lcd display
était supporté sous linux.