Reprise du message précédent :

Bien sûr qu'ils ne sont pas obligés de l'utiliser mais si c'est bien fait pourquoi réinventer la roue une énième fois ?

Je me demande même si c'est pas un peu tôt, car pour l'instant l'intégration au vu d'une distribution stable c'est impossible. Kde n'est pas complet ni fonctionnel ni même performant...

donc en gros il faut plutôt tabler pour le printemps 2009 si on veut une distribution Linux contenant un KDE 4.x stable ET complet

du coup je vais encore rester un petit peu sur ma Mandriva 2007.1

tu peux toujours migrer sur la 2008.1 qui vient de sortir

En même temps, Mandriva.... (j'aime vraiment pas cette distribution, dans le même genre, je préfère OpenSuse).

opensuse 11    Stencore qu'une alpha, mais elle à l'air super bien chiadé  

en meme temps suse .... c'est un peu les gens qui se compromettent quoi....
 
 
 
tout cela pour dire que les ... sans justification c'est mal .

tiens en lisant  ceci, il n'est pas impossible en fait que kde4 soit l'environnement kde par défaut et pas kde3 pour la 2009.0

J'attends de voir question stabilité, KDE 4 n'étant pas du tout au point.

Mandriva depuis la version 2007.0 est devenue une distribution linux incontournable, la plupart des défauts des anciennes versions ont été corrigé

on parle beaucoup d'Ubuntu grâce à la puissance commerciale et marketing du milliardaire sud-africain qui a lancé ce bizness mais c'est Mandriva le premier qui a réussi à rendre abordable l'adoption de Linux grâce à son installateur 100% graphique et la possibilité de configurer le système avec des outils graphiques sans être obligé de passer par la ligne de commande

donc je ne comprends pas ces à-prioris négatifs sur Mandriva, pour avoir essayé les autres distributions comme Fedora ou Ubuntu Mandriva n'a pas à rougir

Je peux pas me passer de apt-get pour ma part, ou d'un système équivalent type Pacman sous archlinux.

 
+1, le préjugé reste car a tout les coup on va te répondre "ué mais ubuntu c'est basé sur debian " mais mandriva je la trouve déjà plus stable que ubuntu Meme si la gestion des paquets est déstabilisante au départ c'est une bonne distrib pour les débutants.

Pour utiliser les 2 (mandriva et debian), je ne vois pas bien en quoi la gestion des paquets est déstabilisante.
A part le multiarch inexistant avec apt et le manque de résolution inverse des dépendances à la désinstall avec urpmi ; c'est kifkif.

et c'est là où le bât blesse...

tout à fait
Ceci étant dit c'est en cours d'intégration \o/

perso, c'est plus le multiarch qui me manquerait avec dpkg

<HS>
Debian a initié en 2004 un projet de ce type sur Alioth ; courant 2006 il était même question d'intégrer le support multiarch à dpkg pour Etch, mais finalement ça ne c'est pas fait, car il aurait fallu d'une part lourdement patcher dpkg et d'autre part cela demandait aussi beaucoup de travail du côté de APT.
 
Dans le futur, une réécriture de dpkg (dpkg2) a déjà été envisagée, pour l'optimiser mais surtout pour étendre ses fonctionnalités ; le travail effectué sur dpkg-multiarch fera sans doute l'objet d'une intégration à ce moment-là, ce qui ne se produira pas avant Lenny+1, je pense.
</HS>

Euh le multiarch vous voulez dire quoi au juste ?
(pour avoir tester les deux, le probleme de mandriva est, à mon gout, que tu sens qu'y a petit aspect commercial derrière, et les dépots m'ont semblé moins rempli (j'ai p-e pas eu de chance avec les paquets qui m'intéressent cependant))
 
Sinon pour en revenir au sujet, que pensez-vous de kickoff (en attendant raptor)

le multiarch, ça veut dire que je peut installer sans problème un paquet en 32 bits au milieu d'une distribution 64 bits, idem pour les libs. Le tout sans avoir besoin de passer par un chroot.

normalement si vous êtes un utilisateur avancé de Linux alors vous pouvez aussi installer vos programmes en compilant le code source

./configure
make
su
make install

et pour désinstaller:
make uninstall

c'est pas sorcier à condition de bien lire le fichier readme et INSTALL

pour certains logiciels comme VLC dont les RPM tardent à venir dans les dépots pour les dernieres versions alors souvent la compilation personnelle est la meilleure solution

de plus ça permet d'optimiser le binaire selon le type de CPU que l'on a en modifiant les parametres de la variable CFLAGS

1. Pour installer via la compilation mieux vaut rajouter une étape de packaging pour qu'il s'intègre dans ta distrib. De très bon outils vont ca simplement.
2. pour la désinstallation tout les Makefile ne fournissent pas forcément la cible uninstall... et là pour jarter tous les fichiers... tu vas t'amuser si t'es pas passé par un package...

que veux-tu dire par "qu'il s'integre dans ta distrib" ?

le but est de créer un raccourci vers le programme dans le menu KDE ou Gnome ?

ça tu peux le faire à la main

et dans les options de ./configure tu peux spécifier tout un tas de paramètres comme le dossier d'installation si tu veux personnaliser l'installation,

comme je le disais il arrive assez souvent que la dernière version du logiciel que l'on souhaite installer ne possède aucun système de package à la RPM,

cela m'est arrivé pour la dernière version de VLC ( 0.8.6.f ), il n'y avait rien dans les dépots de Mandriva 2007.1,

idem pour le jeu flight gear 1.0.0 ( il y avait que la version 0.9.10 )

du coup t'es bien obligé d'installer avec la méthode old school cad compiler, à moins de se contenter de l'ancienne version du logiciel

pour le "make uninstall" c'est en général prévu pour les logiciels ayant une certaine renommée,

pour les petits jeux si il y a pas de uninstall c'est pas grave, il suffit de virer le repertoire où les binaires sont installés ( /usr/games/mon_jeu par exemple ) et eventuellement virer les fichiers de config du jeu présents dans /home

Je ne dis pas le contraire
Je dis simplement que si tu passes par la compilation tu ferais mieux de passer par une étape de packaging et qu'après tu installes le package proprement.

Et c'est quoi le problème d'avoir une version un peu ancienne ? tu n'as pas forcément besoin de la toute dernière fonctionnalité. Personnellement je passe à des versions nouvelles dans les cas suivants :
- correction de bug grave
- correction de faille de sécurité
- ajout de fonctionnalité intéressante pour moi.
 
 
 

 
Pour les petits binaires simples oui...
 
Au lieu de me poser la question  a chaque fois, je pars du principe qu'un coup de checkinstall ca mange pas de pain...

pourquoi rajouter une étape supplémentaire si au final la compilation permet une installation propre et qu'il existe une option "make uninstall" ?

si le fichier readme et INSTALL est suffisament documenté ( au niveau des dépendances notamment ) et qu'ils offrent suffisamment d'options pour personnaliser l'installation alors personnellement je n'hésite pas à compiler

la dernière version de VLC corrige une faille de sécurité assez importante, c'est pour ça que j'ai preferé ne pas attendre le RPM,

en général les developpeurs ne s'amusent pas à sortir des nouvelles versions juste pour le plaisir d'avoir un numéro de version plus elevé, il y a toujours de bonnes raisons comme celles que tu cites

mais tu as aussi raison lorsque tu dis que l'on a pas forcément besoin de la toute dernière feature du logiciel  

et quand on est un utilisateur expert de linux, on sait ce qu'est un paquet source (src.rpm par ex).

 
nan ogure a raison, ca vaut bien mieux de faire un package deb ou rpm à partir de tes sources et d'installer ce package.
je ne connais pas pour les autres distros, pour debian c'est tres simple au lieu de make install un simple checkinstall et c'est fait.
ainsi, pas besoin de garder le paquet source, et tout le souk qui va avec, le versioning des paquets est géré (si une version plus récente arrive dans les repositories, le package sera remplacé).

bon vous avez raison je le reconnais en ce qui concerne la nécessité de créer un package

je suis plutôt old-school et adepte des solutions directes, comme pour l'instant la méthode d'installation à base de compilation des sources ne m'a jamais crée de soucis alors je ne me suis pas attardé sur les possibilités offertes par le système des packages

Normalement si tu es un utilisateur avancé de Linux, tu ne fais jamais de make install

Ah merde, grillé

Rappelez moi le nom du topic ?

là on parle pas vraiment de réinventer là roue, mais bon, qd t'es passionné, abandonner ton travail pour utiliser un dérivé réalisé par qq1 d'autre sur lequel tu as bcp moins la main, c'est pas forcément super intéressant.
Surtout que WebKit n'est pas un projet Trolltech, c'est le port Qt de celui ci qui l'est, le moteur reste hébergé chez Apple et les différentes versions sont gérées dans des branches (une pour safari, une pour Qt, etc.) donc ça peut être une bonne idée d'en rajouter une pour konqueror mais j'peux comprendre que les dev de KHTML soient pas forcément super chaud . En plus à terme ça va être rigolo de merger les branches de WebKit

Au final les différents WebKit ils ont quoi en commun ?

ça dépend ce que t'appelles les différents WebKit

Le créateur de KHTML travaille sur QtWebkit si je ne me trompe pas

Le webkit en C++ pur et le webkit en Qt.

 
parce que QT n'est pas écrit en C++ pur ?
 
http://fr.wikipedia.org/wiki/Qt

Vous avez très bien compris ce que je voulais dire ...

Euh non .

Il y a le webkit utilisé dans Safari et le webkit de Trolltech.

Le webkit de Trolltech ? Ils l'ont pas forké si ?
Me semblait qu'il avait juste construit un nouveau module pour qt (qtwebkit) mais pas qu'il allait se mettre à dev webkit .

Bah je sais pas trop c'est moi qui posait les questions si tu remontes un peu les messages.