> En effet, Debian précise bien que la sortie de la Debian suivante se fait quand elle est prête, et non à date fixée.
S'il n'y a pas de planning, on peut se demander s'il y a un pilote dans d'avion.
Et ça : http://linuxfr.org/2003/08/19/13677.html(...) Anthony Towns, le Debian Release Manager, est prêt à lancer une politique agressive (ce sont ses termes, aux faux-amis près) pour obtenir une version stable de Debian pour le 1er décembre... de cette année, que croyiez-vous ? ;)
"cette année", c'est 2003 :-)
> C'est d'ailleurs ce qui fait sa qualité exemplaire...
Mouaif... C'est pas difficile à ce rythme la. Surtout que tout est débuggé par les autres distributions qui diffusent ce qui sera utilisé par Debian dans x mois voir année.
All packages that are included in the official Debian distribution are free according to the Debian Free Software Guidelines. This assures free use and redistribution of the packages and their complete source code. The official Debian distribution is what is contained in the main section of the Debian archive.
As a service to our users, we also provide packages in separate sections that can not be included in the main distribution due to either a restrictive license or legal issues. They include:
Contrib
Packages in this area are freely licensed by the copyright holder but depend on other software that is not free.
Non-Free
Packages in this area have some onerous license condition restricting use or redistribution of the software.
Non-US/Main
Packages in this area are free themselves but cannot be exported from a server in the U.S.
Non-US/Non-Free
Packages in this area have some onerous license condition restricting use or redistribution of the software. They cannot be exported from the U.S. because they are encryption software packages that are not handled by the export control procedure that is used for the packages in Main or they cannot be stored on a server in the U.S because they are encumbered by patent issues.
Ça dépend. Il faut passer par un loopback (device mapper depuis 2.6). Dans ce cas tout le fs (en fait le périphérique) est crypté. Ce n'est pas fait par fichier et c'est indépendant du système de fichier (tu peux même avoir une vfat crypté :-)).
ext3, xfs, reiserfs. ext3 et xfs on aussi les attributs étendus (utilisé par exemple pour SeLinux).
Pour le reste, je ne sais pas ce que c'est.
Le plus gros défaut d'ntfs n'est pas la fragmentation, mais que ce soit si abominablement long à défragmenter...
> The current latest production release is: 4.1
> Mais aprés ça, rpm est libre, il est pas sous le controle de redhat ( ça fait que 3 fois que je le fait remarquer, je devrait bosser sur mon fork plutot )
Ben il faut taper dans le CVS : http://www.rpm.org/cvs_help/(...)
head CHANGES (du cvs) :
4.3.1 -> 4.4:
- pentium3/pentium4 arch support (pluto@PLD).
- cpuid() cleanups for PIC/non-PIC and gcc 3.4 (pluto@PLD).
- rpmGlob() is now locale independent (wiget@PLD).
> [gb@galois T]$ sudo rpm -Fvh test-x86_64-2.1-2mdk.amd64.rpm
> libtest1-2.1-2mdk.amd64.rpm
> error: Failed dependencies:
> libtest.so.0 is needed by (installed) test-i386-2.1-1mdk
Je n'ai pas eu un opteron sous la main bien longtemps. J'avais testé Opteron avec rpm v4.3.1.
Il y a effectivement un problème dans l'exemple que tu me donnes. Il ne me semble pas qu'il y est de raisons valides pour refuser la mise à jour.
Peut-être que libtest1 a un fichier de configuration commun à i586 et amd64. Si c'est le cas, il est normal que la mise à jour soit refusée. Sinon tu aurais le même fichier de configuration pour deux versions différentes de libtest1 (2.1-1mdk et 2.1-2mdk).
Le problème semble la mise à jours de libtest et non de test-x86_64.
Peux-tu donner la sortie de "rpm -qlp libtest1-2.1-1mdk.amd64.rpm libtest1-2.1-1mdk.i586.rpm" ?
D'après le message d'erreur, il semble qu'une partie des dépendances est ignorée. C-à-d que rpm considère "libtest.so.0" et non "libtest.so.0()(64bit)".
> Bref, il faut donc la même version-release du package de libs avec la méthode rpm standard, comme initialement indiqué.
Donnes la sortie de "rpm -qlp libtest1-2.1-1mdk.amd64.rpm libtest1-2.1-1mdk.i586.rpm" avant que j'avoue mon erreur :-)
Normal, libtest1-2.1-1mdk.i586.rpm n'est pas requis par un autre paquet i386.
Si libtest1-2.1-1mdk.i586.rpm était utilisé, la mise à jours de la lib x86_64 serait refusée et libtest1-2.1-1mdk.i586.rpm ne serait pas viré
> Et un soft ou tu as besoin de placer 2000 ligne de modifications avant que ça marche comme tu veut et comme ça devrait, ça me semble être assez énorme.
Regarde le noyau Mandrake, c'est "énorme", vraiment énorme la quantité de patch. Vas te plaindre sur la lkml ou fais un fork si tu veux.
> En 400 ligne, un patch rajoute à peu prés une fonctionnalité non trivial, donc 2000 lignes de corrections de bugs toujours non intégrés upstream
upstream en est à la version 4.3.1 et non à la version 4.2.2 .
> et comme je le disait, mandrake n'est pas la seul distrib à faire ça
Cherche les patchs Suse qui sont aussi dans Mandrake.
Il n'y en a pas. Les patchs Suse et Mandrake sont spécifiques. Donc je ne soit pas pourquoi il devraient être en upstream.
> ce qui prouve bien que tout le monde est con sauf redhat.
> tu peux avoir des conflits par exemple juste à cause des %doc.
Faux.
> De même, rpm ne gérait des installs de packages biarch que s'ils avaient la même version-release exactement.
Faux. Ou du moins on ne peut pas faire tout et n'importe avec rpm. Si une librairie utilise un fichier de configuration dont le chemin est codé dur, il va de soit qu'il faut la même version-release.
> Par ailleurs, quand ensuite tu veux *mettre à jour* l'un des packages ben tu étais couillonné: l'autre instance disparaissait de la base rpm.
Faux. Par contre, comme au-dessus on ne peut pas faire tout et n'importe quoi. Si en biarch une librairie a des fichiers de conf en dure, il faut exactement la même version-release. Ce n'est pas une contrainte rpm.
> Au fait, j'indique au passage que la version officielle de rpm 4.2.2 n'est pas triviale à trouver, i.e. ce n'est pas celle de rpm.org.
???
> Par ailleurs, il est intéressant de noter que même RedHat commence à libifier un peu ses packages de sorte à limiter les conflits possible lors d'installation de packages ia32/amd64 en parallèle.
Pourquoi commence ?
> Sous Mandrakelinux, tu peux installer n'importe quel lot de packages libifiés sans aucun conflit et qui peuvent être mis à jour indépendamment, l'un de l'autre.
Regardes, il y a des paquets i386 et x86_64. Les deux paquets suivants s'installe en parallèle sans problème :
XFree86-Mesa-libGL-4.3.0-55.i386.rpm
XFree86-Mesa-libGL-4.3.0-55.x86_64.rpm
yum et up2date gère ça. Sous Fedora core 1 un "yum install mozilla" va récupéré les librairies i386 nécessaires si tu es sous x86_64 (sous FC1 mozilla est i386). Un "yum install XFree86-Mesa-libGL.i386" marche aussi.
C'est RedHat qui a ajouté ce support (rpm V4.2). C'était dans Rawhide avant la sortie de la RH 8.0 qui utilisait rpm V4.2.
Tu vas m'explique que RedHat, qui developpe rpm, ne sait pas utiliser rpm ?!
> a version + le support est beaucoup plus important.
Et si le gus il en a rien à foutre du support "beaucoup plus important". Si il veut seulement une disbribution boîte avec des services serveurs. Si en fait ce qu'il veut c'est une PowerPack et pas plus ! Mais ces crétins du marketing Mandrake lui cachent que la PowerPack a les services serveurs et que donc il va se faire entubé en achetant une PowerPack+ car selon les sites officiel Mandrake il n'y a que la PowerPack+ qui fait serveur (ce qui est un mensonge).
Tu vas lui expliqué que c'est un con et qu'il doit débourser 199 au-lieu de 79,9 ?
Je suis fatigué. Les utilisateurs de Mandrake sont d'une incrédulité désarmante.
Vive Mandrake ! Ses conneries et ses mensonges !
Et Vive ses supportaires ! Ça doit pas être facile tout les jours vu les agissements du marketing de Mandrake.
Ce dernière dérapage va se savoir commes les buggues à répétition de Mandrake. Préparez un bon argumentaire.
#(!) summary for main lib RPM only
Summary: Main library for gtkmm
Group: System/Libraries
Provides: %{name} = %{version}-%{release} <========= inutile
%description -n %{lib_name}
This package contains the library needed to run programs dynamically
linked with gtkmm.
%package -n %{lib_name}-devel
Summary: Headers for developing programs that will use Gtk--
Group: Development/GNOME and GTK+
Requires: %{lib_name} = %{version}
#(!) **MANDATORY**
Provides: %{lib_name_orig}-devel = %{version}-%{release} <========== pourquoi ?
#(!) **MANDATORY**
Provides: %{name}-devel = %{version}-%{release} <============= Pourquoi ?
Dans mon exemple imaginaire ( http://linuxfr.org/comments/393281.html(...) ), le type achète une PowerPack+ à 199 car Mandrake ne dit pas qu'il y a les services serveurs dans la PowerPack à 79,9 . Si mandrake (son marketing) ne mentait pas, le gus n'aurait pas dépensé 199 puisque la PowerPack à 79,9 répond à son besoin.
Ce type c'est fait entubé.
Un autre type qui est au courrant des pratiques de Mandrake et qui a le même besoin, va prendre un PowerPack à 79,9 (et il ne se sera pas fait entubé).
Je viens de vérifier et maintenant je sais. C'est toujours le même bordel.
> La plupart des requires sont fait via un script automatique, sur fedora comme sur mdk
Je parle des "Requires:" dans le fichier spec. Ils sont ajouté manuellement.
> compare www.zarb.org/~misc/find-requires.mdk avec www.zarb.org/~misc/find-requires.fdr
Fedora utilise une méthode automatique et standard (c'est dans le rpm d'origine). Mandrake ne fait rien en automatique (selon ton url mais je pense que c'est une erreur).
> Par exemple, celui de mdk fait les dépendances entre bibliothéques
J'ai regardé find-req.pl et c'est une connerie de faire ça. Ça ajoute des dépendances inutiles. Si un programme a uniquement besoin de libX11.so je ne vois pas pourquoi il faut ajouter libc puisque le paquet qui fournit libX11.so a déjà cette dépendance. Aucun intérêt. C'est uniquement pour empêcher l'installation sur une autre bécane.
> pour les entetes, les .h
Non, c'est fait dans le .spec et manuellement (ce sont les "BuildRequires:"). les find-req* ne sont pas utilisé pour contruire les fichiers .spec (évidemment...).
> Donc, je croit pas que dire que mdk fait moins de choses automatisés soit la meilleur des tes idées de la journées.
Le problème ce sont les ajouts manuelles dans le fichier .spec qui ne servent à rien. (idem lors de la création de rpm avec find-req.pl).
> Je suis pas sur que tu sais ce que c'est que de maintenir un patch de 2000 ligne sur un truc aussi critique et aussi sensible que rpm, qui, avec 1 000 000 de ligne de codes
Manifestement tu ne sais pas ce que c'est que de maintenir un projet aussi critique et aussi sensible que rpm qui fait 1 000 000 de lignes de code.
> Ça veut donc bien dire que rh refuse le boulot des autres
Ben que les autres fassent le boulot de RedHat pour avoir le "privilège" de refuser les contributions de RedHat.
> D'ailleurs, le fait que ça soit pas compatible comme tu dit
Ce n'est pas rpm qui n'est pas compatibible. C'est mandrake qui ajoute des requires inutiles dans les fichiers spec par exemple.
Avec Mandrake au-lieu d'avoir un simple "Requires: libtoto.so.0" (fait automatiquement) il y a aussi "Requires: libtoto0". Si mon système à libtoto.so.0, ce n'est pas suffisant. Il faut aussi que le paquet qui fournit libtoto.so.0 soit nommé libtoto0 . Ce n'est pas du ressort de rpm mais du distributeur.
Il y a toujours eu compatibilité ascendante dans rpm. Sauf pour RH8.0 (introduction de rpm V4.2) si mes souvenirs sont bons (corrigé en errata).
> Tu serais pas en train de te contredire toi meme, à m'exorter à forker rpm
C'est toi qui te contredit. C'est toi qui croit que Mandrake est proche du fork car rpm est "parait-il" mal maintenu. Moi je pense que Mandrake est satisfait par le boulot fait dans rpm (même s'ils doivent gérer un patch de 2000 lignes).
Pour preuve, ils ne font pas de fork.
> Remarque je croit que tu n'est plus à ça prêt...
Tu ne lis pas bien mes posts et en plus tu ne lis pas les tiens...
> Le but, c'est tout de meme de coller à un standard.
Ben le standard c'est http://www.rpm.org/(...) . Si ça ne te plait pas, fait un fork. Un fork c'est le truc qui c'est passé avec XFree86 et Xorg par exemple.
Je ne sais pas si Mandrake a changé mais le standard est de ne pas mettre des Requires inutiles comme le fait Mandrake mais de s'appuier sur l'autodétection que faire rpm. Cette méthode Mandrake est un truc formidable pour empêcher d'installation d'un paquet Mandrake sur une autre bécane (même depuis les sources).
> Trop sympa, merci rh.
Trop sympa pour un mec comme toi.
Démonstration :
> Quand tu regarde le nombre de patch sur rpm de mdk
[^] # Re: Rooooooooooooohhh
Posté par 007 . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 0.
S'il n'y a pas de planning, on peut se demander s'il y a un pilote dans d'avion.
Et ça :
http://linuxfr.org/2003/08/19/13677.html(...)
Anthony Towns, le Debian Release Manager, est prêt à lancer une politique agressive (ce sont ses termes, aux faux-amis près) pour obtenir une version stable de Debian pour le 1er décembre... de cette année, que croyiez-vous ? ;)
"cette année", c'est 2003 :-)
> C'est d'ailleurs ce qui fait sa qualité exemplaire...
Mouaif... C'est pas difficile à ce rythme la. Surtout que tout est débuggé par les autres distributions qui diffusent ce qui sera utilisé par Debian dans x mois voir année.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par 007 . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 0.
A force de mettre de plus en plus de chose dans non-free, la vraie question est :
à quand Debian dans non-free ?
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par 007 . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 1.
C'est un peu de la langue de bois.
http://www.debian.org/distrib/packages(...) :
Introductory notes
All packages that are included in the official Debian distribution are free according to the Debian Free Software Guidelines. This assures free use and redistribution of the packages and their complete source code. The official Debian distribution is what is contained in the main section of the Debian archive.
As a service to our users, we also provide packages in separate sections that can not be included in the main distribution due to either a restrictive license or legal issues. They include:
Packages in this area are freely licensed by the copyright holder but depend on other software that is not free.
Packages in this area have some onerous license condition restricting use or redistribution of the software.
Packages in this area are free themselves but cannot be exported from a server in the U.S.
Packages in this area have some onerous license condition restricting use or redistribution of the software. They cannot be exported from the U.S. because they are encryption software packages that are not handled by the export control procedure that is used for the packages in Main or they cannot be stored on a server in the U.S because they are encumbered by patent issues.
C'est Debian qui fournit du non-free.
# Re: La sortie de la prochaine Debian menacée ?
Posté par 007 . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 0.
C'est de la masturbation intellectuelle.
# Re: Mandrake 9.2 je te hais
Posté par 007 . En réponse au journal Mandrake 9.2 je te hais. Évalué à 1.
Ou GNU/Hurd 1.0.
[^] # Re: Les différentes versions du noyau : vanilla, tmb, mdk, mm, ...
Posté par 007 . En réponse au journal Les différentes versions du noyau : vanilla, tmb, mdk, mm, .... Évalué à 0.
Maintenant c'est en standard dans Linux 2.6 et glibc.
# Re: OSDL rejoint par AMD
Posté par 007 . En réponse à la dépêche OSDL rejoint par AMD. Évalué à 5.
http://www.mandrakelinux.com/en/100amd64beta.php3(...)
[^] # Re: Quid de la stabilité ?
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 1.
ext3 le fait. D'autres aussi ?
> - encryption
Ça dépend. Il faut passer par un loopback (device mapper depuis 2.6). Dans ce cas tout le fs (en fait le périphérique) est crypté. Ce n'est pas fait par fichier et c'est indépendant du système de fichier (tu peux même avoir une vfat crypté :-)).
> - compression
http://e2compr.sourceforge.net/(...)
Pas très bien maintenu maintenant. Je l'utilisais sous Linux 2.2 et ça marchait nickel.
> - ACL
ext3, xfs, reiserfs. ext3 et xfs on aussi les attributs étendus (utilisé par exemple pour SeLinux).
Pour le reste, je ne sais pas ce que c'est.
Le plus gros défaut d'ntfs n'est pas la fragmentation, mais que ce soit si abominablement long à défragmenter...
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 0.
Ben je ne savais pas où était ton fichier alors j'ai cherché rapidement et j'ai pris le premier qui avait le même nom et était plus vieu.
C'est tout.
> Celui qui marche pas, c'est le fichier la
> http://katu3.zarb.org/~misc/heartbeat-0.4.9-1mdk.src.rpm(...)
Marche pas ici.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à -1.
J'ai testé avec ftp://ftp.proxad.net/pub/Distributions_Linux/Mandrakelinux/old/7.2(...)
$ file heartbeat-0.4.8-3mdk.src.rpm
heartbeat-0.4.8-3mdk.src.rpm: RPM v3 src i386 heartbeat-0.4.8-3mdk
$ rpm -qpl heartbeat-0.4.8-3mdk.src.rpm
attention: heartbeat-0.4.8-3mdk.src.rpm: signature V3 DSA: NOKEY, key ID 9b4a4024
authkeys
ha.cf
haresources
heartbeat-0.4.8.tar.bz2
heartbeat.spec
ldirectord-init.patch
www.cf
$ rpm2cpio heartbeat-0.4.8-3mdk.src.rpm | cpio -tv
-rw------- 1 546 546 641 Aug 30 2000 authkeys
-rw-r--r-- 1 546 546 1427 Aug 30 2000 ha.cf
-rw-r--r-- 1 546 546 3905 Aug 30 2000 haresources
-rw-r--r-- 1 546 546 141688 Aug 30 2000 heartbeat-0.4.8.tar.bz2
-rw-r--r-- 1 546 546 13294 Sep 12 2000 heartbeat.spec
-rw-r--r-- 1 546 546 616 Sep 12 2000 ldirectord-init.patch
-rw-r--r-- 1 546 546 522 Aug 31 2000 www.cf
319 blocks
$ rpm -v | head -n 1
RPM version 4.3.1
> The current latest production release is: 4.1
> Mais aprés ça, rpm est libre, il est pas sous le controle de redhat ( ça fait que 3 fois que je le fait remarquer, je devrait bosser sur mon fork plutot )
Ben il faut taper dans le CVS : http://www.rpm.org/cvs_help/(...)
head CHANGES (du cvs) :
4.3.1 -> 4.4:
- pentium3/pentium4 arch support (pluto@PLD).
- cpuid() cleanups for PIC/non-PIC and gcc 3.4 (pluto@PLD).
- rpmGlob() is now locale independent (wiget@PLD).
4.3 -> 4.3.1:
...
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 4.
9... 8... 7... 6... 5... 4... 3... 2... 1... 0
Gwenole Beauchesne vainqueur par KO.
PS : rien vu dans le CHANGELOG de rpm qui indique une correction entre v4.2.2 et v4.3.1.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 0.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 0.
> libtest1-2.1-2mdk.amd64.rpm
> error: Failed dependencies:
> libtest.so.0 is needed by (installed) test-i386-2.1-1mdk
Je n'ai pas eu un opteron sous la main bien longtemps. J'avais testé Opteron avec rpm v4.3.1.
Il y a effectivement un problème dans l'exemple que tu me donnes. Il ne me semble pas qu'il y est de raisons valides pour refuser la mise à jour.
Peut-être que libtest1 a un fichier de configuration commun à i586 et amd64. Si c'est le cas, il est normal que la mise à jour soit refusée. Sinon tu aurais le même fichier de configuration pour deux versions différentes de libtest1 (2.1-1mdk et 2.1-2mdk).
Le problème semble la mise à jours de libtest et non de test-x86_64.
Peux-tu donner la sortie de "rpm -qlp libtest1-2.1-1mdk.amd64.rpm libtest1-2.1-1mdk.i586.rpm" ?
D'après le message d'erreur, il semble qu'une partie des dépendances est ignorée. C-à-d que rpm considère "libtest.so.0" et non "libtest.so.0()(64bit)".
> Bref, il faut donc la même version-release du package de libs avec la méthode rpm standard, comme initialement indiqué.
Donnes la sortie de "rpm -qlp libtest1-2.1-1mdk.amd64.rpm libtest1-2.1-1mdk.i586.rpm" avant que j'avoue mon erreur :-)
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 0.
> libtest1-2.1-1mdk
> libtest1-2.1-1mdk
Normale, il faut faire :
$ rpm -q -a --queryformat "%{NAME}-%{ARCH}"
Faire rpm --querytags pour avoir la liste des tags.
> [gb@galois T]$ rpm -qa "libtest*"
> libtest1-2.1-2mdk
Normal, libtest1-2.1-1mdk.i586.rpm n'est pas requis par un autre paquet i386.
Si libtest1-2.1-1mdk.i586.rpm était utilisé, la mise à jours de la lib x86_64 serait refusée et libtest1-2.1-1mdk.i586.rpm ne serait pas viré
Bref, ça marche bien.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 0.
Exemple ?
Voilà un petit essai sur ma bécane avec la dernière version de rpm (v4.3.1).
récupération d'un paquet de RedHat 4.2 (1998) ! :
http://updates.redhat.com/4.2/en/os/i386/initscripts-2.96-1.i386.rp(...) .
$ rpm -q -i -p initscripts-2.96-1.i386.rpm
[blabla]
Build Date: jeu 16 jui 1998 09:25:37 CEST
[blabla]
$ rpm -q --scripts -p initscripts-2.96-1.i386.rpm
postinstall scriptlet (using /bin/sh):
if [ ! -f /var/log/wtmp ]; then
touch /var/log/wtmp
fi
$ rpm -q -l -p initscripts-2.96-1.i386.rpm
/bin/doexec
/etc/adjtime
/etc/inittab
[...]
$ rpm2cpio initscripts-2.96-1.i386.rpm | cpio -tv
-rwxr-xr-x 1 root root 2484 Jul 16 1998 bin/doexec
-rw-r--r-- 1 root root 10 Jul 16 1998 etc/adjtime
-rw-r--r-- 1 root root 1726 Jul 16 1998 etc/inittab
-rwxr-xr-x 1 root root 311 Apr 2 1997 etc/ppp/ip-up
[...]
$ rpm -q --dump -p initscripts-2.96-1.i386.rpm
attention: initscripts-2.96-1.i386.rpm: signature V3 RSA/MD5: NOKEY, key ID cba29bf9
/bin/doexec 2484 900573933 b4a852528210ffe7b1c635346c3f7de1 0100755 root root 0 0 0 X
/etc/adjtime 10 900573933 f2d1b25a9d592f6d572c99ff8a387de9 0100644 root root 1 0 0 X
/etc/inittab 1726 900573933 236579289bec9029e3f5b9e5c501aed1 0100644 root root 1 0 0 X
/etc/ppp/ip-up 311 859996930 8d44b69271b7b0ed8b54f90023181bf2 0100755 root root 1 0 0 X
[...]
Pas de problème.
> Et un soft ou tu as besoin de placer 2000 ligne de modifications avant que ça marche comme tu veut et comme ça devrait, ça me semble être assez énorme.
Regarde le noyau Mandrake, c'est "énorme", vraiment énorme la quantité de patch. Vas te plaindre sur la lkml ou fais un fork si tu veux.
> En 400 ligne, un patch rajoute à peu prés une fonctionnalité non trivial, donc 2000 lignes de corrections de bugs toujours non intégrés upstream
upstream en est à la version 4.3.1 et non à la version 4.2.2 .
> et comme je le disait, mandrake n'est pas la seul distrib à faire ça
Récupères le rpm de Suse :
ftp://ftp.suse.com/pub/suse/i386/9.0/suse/src/rpm-4.1.1-77.src.rpm(...)
Cherche les patchs Suse qui sont aussi dans Mandrake.
Il n'y en a pas. Les patchs Suse et Mandrake sont spécifiques. Donc je ne soit pas pourquoi il devraient être en upstream.
> ce qui prouve bien que tout le monde est con sauf redhat.
C'est pas gentil pour les autres.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à -1.
Faux.
> De même, rpm ne gérait des installs de packages biarch que s'ils avaient la même version-release exactement.
Faux. Ou du moins on ne peut pas faire tout et n'importe avec rpm. Si une librairie utilise un fichier de configuration dont le chemin est codé dur, il va de soit qu'il faut la même version-release.
> Par ailleurs, quand ensuite tu veux *mettre à jour* l'un des packages ben tu étais couillonné: l'autre instance disparaissait de la base rpm.
Faux. Par contre, comme au-dessus on ne peut pas faire tout et n'importe quoi. Si en biarch une librairie a des fichiers de conf en dure, il faut exactement la même version-release. Ce n'est pas une contrainte rpm.
> Au fait, j'indique au passage que la version officielle de rpm 4.2.2 n'est pas triviale à trouver, i.e. ce n'est pas celle de rpm.org.
???
> Par ailleurs, il est intéressant de noter que même RedHat commence à libifier un peu ses packages de sorte à limiter les conflits possible lors d'installation de packages ia32/amd64 en parallèle.
Pourquoi commence ?
> Sous Mandrakelinux, tu peux installer n'importe quel lot de packages libifiés sans aucun conflit et qui peuvent être mis à jour indépendamment, l'un de l'autre.
Comme les autres.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à -1.
Ça ne les intéressent pas alors que c'est eux qui l'ont fait. N'importe quoi toi. T'es bizarre dans ta tête.
C'est dans rawhide depuis bien longtemps.
RedHat le fait depuis la RHEL 3.
Fedora Core 1 le fait :
http://fr2.rpmfind.net/linux/fedora/core/1/x86_64/os/Fedora/RPMS/(...)
Fedora Core 2 test 2 le fait :
http://fr2.rpmfind.net/linux/fedora/core/test/1.91/x86_64/os/Fedora(...)
et Fedora Core 2 final le fera.
Regardes, il y a des paquets i386 et x86_64. Les deux paquets suivants s'installe en parallèle sans problème :
XFree86-Mesa-libGL-4.3.0-55.i386.rpm
XFree86-Mesa-libGL-4.3.0-55.x86_64.rpm
yum et up2date gère ça. Sous Fedora core 1 un "yum install mozilla" va récupéré les librairies i386 nécessaires si tu es sous x86_64 (sous FC1 mozilla est i386). Un "yum install XFree86-Mesa-libGL.i386" marche aussi.
C'est RedHat qui a ajouté ce support (rpm V4.2). C'était dans Rawhide avant la sortie de la RH 8.0 qui utilisait rpm V4.2.
Tu vas m'explique que RedHat, qui developpe rpm, ne sait pas utiliser rpm ?!
Et ben va y, on est plus à une connerie prèt.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à -2.
> a version + le support est beaucoup plus important.
Et si le gus il en a rien à foutre du support "beaucoup plus important". Si il veut seulement une disbribution boîte avec des services serveurs. Si en fait ce qu'il veut c'est une PowerPack et pas plus ! Mais ces crétins du marketing Mandrake lui cachent que la PowerPack a les services serveurs et que donc il va se faire entubé en achetant une PowerPack+ car selon les sites officiel Mandrake il n'y a que la PowerPack+ qui fait serveur (ce qui est un mensonge).
Tu vas lui expliqué que c'est un con et qu'il doit débourser 199 au-lieu de 79,9 ?
Ben moi je vais lui dire de prendre une Suse à 80 (c'est le même prix mais le marketing Suse ne prend pas ses clients pour des cons).
Ou une Debian ou une Fedora à 10 $ :
http://www.loadux.com/debian.html(...)
http://www.loadux.com/fedora.html(...)
Voir même un Mandrake 10 Official à 10 $ :
http://www.loadux.com/mandrake.html(...)
Je suis fatigué. Les utilisateurs de Mandrake sont d'une incrédulité désarmante.
Vive Mandrake ! Ses conneries et ses mensonges !
Et Vive ses supportaires ! Ça doit pas être facile tout les jours vu les agissements du marketing de Mandrake.
Ce dernière dérapage va se savoir commes les buggues à répétition de Mandrake. Préparez un bon argumentaire.
Ça fait du bien. Merci.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 0.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à -1.
%define name gtkmm
%define version 1.2.4
%define release 1mdk
%define lib_name_orig lib%{name}
%define lib_major 1.2
%define lib_name %mklibname %{name} %{lib_major}
Name: %{name}
#(!) summary for SRPM only
Summary: C++ interface for popular GUI library gtk+
Version: %{version}
Release: %{release}
%description
#Full and generic description of the whole package. (this will be the SRPM
#description only)
#main package (contains *.so.[major].* only)
%package -n %{lib_name}
#(!) summary for main lib RPM only
Summary: Main library for gtkmm
Group: System/Libraries
Provides: %{name} = %{version}-%{release} <========= inutile
%description -n %{lib_name}
This package contains the library needed to run programs dynamically
linked with gtkmm.
%package -n %{lib_name}-devel
Summary: Headers for developing programs that will use Gtk--
Group: Development/GNOME and GTK+
Requires: %{lib_name} = %{version}
#(!) **MANDATORY**
Provides: %{lib_name_orig}-devel = %{version}-%{release} <========== pourquoi ?
#(!) **MANDATORY**
Provides: %{name}-devel = %{version}-%{release} <============= Pourquoi ?
Ces trucs là ne sont pas fait sous RedHat/Fedora.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à -2.
Dans mon exemple imaginaire ( http://linuxfr.org/comments/393281.html(...) ), le type achète une PowerPack+ à 199 car Mandrake ne dit pas qu'il y a les services serveurs dans la PowerPack à 79,9 . Si mandrake (son marketing) ne mentait pas, le gus n'aurait pas dépensé 199 puisque la PowerPack à 79,9 répond à son besoin.
Ce type c'est fait entubé.
Un autre type qui est au courrant des pratiques de Mandrake et qui a le même besoin, va prendre un PowerPack à 79,9 (et il ne se sera pas fait entubé).
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 1.
Je viens de vérifier et maintenant je sais. C'est toujours le même bordel.
> La plupart des requires sont fait via un script automatique, sur fedora comme sur mdk
Je parle des "Requires:" dans le fichier spec. Ils sont ajouté manuellement.
> compare www.zarb.org/~misc/find-requires.mdk avec www.zarb.org/~misc/find-requires.fdr
Fedora utilise une méthode automatique et standard (c'est dans le rpm d'origine). Mandrake ne fait rien en automatique (selon ton url mais je pense que c'est une erreur).
> Par exemple, celui de mdk fait les dépendances entre bibliothéques
J'ai regardé find-req.pl et c'est une connerie de faire ça. Ça ajoute des dépendances inutiles. Si un programme a uniquement besoin de libX11.so je ne vois pas pourquoi il faut ajouter libc puisque le paquet qui fournit libX11.so a déjà cette dépendance. Aucun intérêt. C'est uniquement pour empêcher l'installation sur une autre bécane.
> pour les entetes, les .h
Non, c'est fait dans le .spec et manuellement (ce sont les "BuildRequires:"). les find-req* ne sont pas utilisé pour contruire les fichiers .spec (évidemment...).
> Donc, je croit pas que dire que mdk fait moins de choses automatisés soit la meilleur des tes idées de la journées.
Le problème ce sont les ajouts manuelles dans le fichier .spec qui ne servent à rien. (idem lors de la création de rpm avec find-req.pl).
> Je suis pas sur que tu sais ce que c'est que de maintenir un patch de 2000 ligne sur un truc aussi critique et aussi sensible que rpm, qui, avec 1 000 000 de ligne de codes
Manifestement tu ne sais pas ce que c'est que de maintenir un projet aussi critique et aussi sensible que rpm qui fait 1 000 000 de lignes de code.
> Ça veut donc bien dire que rh refuse le boulot des autres
Ben que les autres fassent le boulot de RedHat pour avoir le "privilège" de refuser les contributions de RedHat.
> D'ailleurs, le fait que ça soit pas compatible comme tu dit
Ce n'est pas rpm qui n'est pas compatibible. C'est mandrake qui ajoute des requires inutiles dans les fichiers spec par exemple.
Avec Mandrake au-lieu d'avoir un simple "Requires: libtoto.so.0" (fait automatiquement) il y a aussi "Requires: libtoto0". Si mon système à libtoto.so.0, ce n'est pas suffisant. Il faut aussi que le paquet qui fournit libtoto.so.0 soit nommé libtoto0 . Ce n'est pas du ressort de rpm mais du distributeur.
Il y a toujours eu compatibilité ascendante dans rpm. Sauf pour RH8.0 (introduction de rpm V4.2) si mes souvenirs sont bons (corrigé en errata).
> Tu serais pas en train de te contredire toi meme, à m'exorter à forker rpm
C'est toi qui te contredit. C'est toi qui croit que Mandrake est proche du fork car rpm est "parait-il" mal maintenu. Moi je pense que Mandrake est satisfait par le boulot fait dans rpm (même s'ils doivent gérer un patch de 2000 lignes).
Pour preuve, ils ne font pas de fork.
> Remarque je croit que tu n'est plus à ça prêt...
Tu ne lis pas bien mes posts et en plus tu ne lis pas les tiens...
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 0.
Puisque j'ai le specfile du rpm de Mandrake sous la main :
$ grep -c -i ^requires: rpm.spec.*
rpm.spec.mandrake:27
rpm.spec.redhat:7
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à -1.
http://www.mandrakesoft.com/products/10/comparison(...)
http://www.mandrakestore.com/mdkfr/index.php?PAGE=tab_0/menu_0.php&(...)
Désolé d'avoir fait croire que c'était le cas.
> Mandrake donne moins, c'est inadmissible.
> Mandrake donne plus, c'est inadmissible.
Mandrake ment et c'est bien.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par 007 . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 0.
Ben le standard c'est http://www.rpm.org/(...) . Si ça ne te plait pas, fait un fork. Un fork c'est le truc qui c'est passé avec XFree86 et Xorg par exemple.
Je ne sais pas si Mandrake a changé mais le standard est de ne pas mettre des Requires inutiles comme le fait Mandrake mais de s'appuier sur l'autodétection que faire rpm. Cette méthode Mandrake est un truc formidable pour empêcher d'installation d'un paquet Mandrake sur une autre bécane (même depuis les sources).
> Trop sympa, merci rh.
Trop sympa pour un mec comme toi.
Démonstration :
> Quand tu regarde le nombre de patch sur rpm de mdk
Ben regardons rpm de la mdk 10 Official : rpm -i ftp://ftp.proxad.net/pub/Distributions_Linux/Mandrakelinux/officia(...)
$ cd redhat/SOURCES
$ bzcat *patch.bz2 | diffstat | tail -1
56 files changed, 1896 insertions(+), 377 deletions(-)
$ bzcat rpm-4.2.2.tar.bz2 | wc
1048156 3735869 34222080
Vraiment trop sympa RedHat.
> on voir qu'il y a quand meme un leger sentiment de fork dans l'air
2 000 lignes sur 1 000 000 soit 0,2 %. Un très léger sentiment de fork dans l'air. Très léger...
> ne pouvant te targeur que de fud et de troll sur ce site.
Fais avancer ton fork au lieu de dire des conneries.
Il te reste "que" 998 000 lignes ou 99,8 % de rpm.