> Que reproches-tu au système de partitionnement de Debian ? Il est très
> bien !
cfdisk et fdisk redimensionne la fat ? le ntfs ? non.
Mais ça sert jamais, on va prendre un autre. Le support du lvm ?
Non plus.
Donc techniquement, ça pue.
Et oui, bien sur, il y a d'autres installeurs. Ce qui prouve bien que techniquement, celui de debian est pas assez bon.
Il y a pas que le graphique, tu saute trop vite au conclusion. Comme tout les debianneux qui n'ont plus vu ce qui se passe en face depuis des années, omnibulés par le seul truc visible de l'installation, le coté graphique.
> Et de toute facon, une Debian, ca s'installe une fois, et ca s'utilise des
> années ... Alors chipoter pour 2 heures d'installation !
J'ai jamais reinstallé ma mdk depuis la 8.2, date de la premiére install, d'un pc neuf. J'ai du faire plus de cycles d'upgrade que tu as du en faire depuis que tu utilise debian, sauf si tu utilise ça depuis la 2.0.
Toi, tu as pas eu besoin de recompiler le kernel pendant l'install debian sur un serveur pour la prise en charge du raid, comme j'ai pu voir chez certains que je connait.
L'installation 2H et on oublie, tu compte pas les 3 semaines de backports/config que tu te tapes aprés.
Ben tu peut rire, mais les debianneux s'en vantent
Tellement de gens qui forkent, qui refusent de suivre le projet mére, et de suivre les autres. Ensuite, on s'étonne que le projet arrivent pas à fermer tout les bugs RC...
Tellement d'installeurs alternatifs, mais beaucoup moins de remontés au niveau du vrai installeur...
Tellement de dépot alternatifs, au lieu d'aider backports.org.
Ou sont définis formellement les notions de meilleur ou moins bon, chez debian ?
Meilleur techniquement ?
Surement pas, car sinon jamais le systême de partionnement actuel n'aurais pu passer, même avec les standards de meilleur d'il y a deux ans. Peut être avec ceux d'il y 5 ans, oui.
Meilleurs, au niveau de la liberté ?
Alors pourquoi encore supporté nonfree, si ce n'est pour satisfaire les utilisateurs ?
Meilleurs pour l'utilisateur ?
Cette mesure montre clairement que non. Enfin à part les utilisateurs qui sont contents de passer pour des gens plus intégristes que RMS et linus, et à qui on arrive à faire accepter un retard digne de microsoft, malgré un planning déja en retard, et qui sont vachement content d'apprendre que une fois de plus, l'installation debian sur certains serveurs va être reservé à une élite qui sais comment recompiler un kernel pendant l'install sur un serveur.
Ces mêmes utilisateurs qui vont s'étonner que RH vole le marché du serveur, alors que debian serait tellement mieux.
Meilleur au niveau des discussion sans fin que ça engendre ici, oui sans doute, mais je pense pas...
Moi aussi, je trouve que faire des changements si importants alors que sarge doit sortir, c'est abusé.
Si debian s'en tenait à ses objectifs, sarge serait sorti sous peu. Même en s'autorisant un peu ( ~ 6 mois ) de retard, on fout pas tout en l'air 1 mois avant.
Et moi aussi, je trouve aussi que woody pue le moisi, un certain serveur dont je m'occupe est bourré de backport, on est bien obligé dés qu'on veut des features aussi révolutionnaires et unstable que postfix+sasl, clamav et un spamassassin un peu plus à jour que ce que woody propose.
Si jamais il y a encore une discussion ou un changement à faire, debian va encore retardé la distribution, et tenir en otage tout les utilisateurs de la stable ?
On tient pas compte des gens qui veulent une version stable sur leur serveur, à qui on promet depuis 1 an des "sarge va sortir bientot", des personnes qui répète ça et qui au final se retrouve un peu ridicule, du travail en plus pour un admin à qui on demande de mettre des trucs plus récents ?
j'ai rien contre le fait que debian nettoie son kernel et la doc de sa glibc car elle contient des morceaux pas assez libre pour elle.
Mais repoussé indéfiniment la release, et au final ne pas vraiment régler le probléme ( car tout le monde va finalement ajouter non-free dans le sources.list, banalisant par la même son utilisation, et rendant son éviction encore plus difficile ), c'est stupide.
La solution adopté, c'est juste pour l'apparence, une masquerade.
Conectiva ( http://conectiva.br(...) ) utilise subversion en interne, d'aprés un poste sur la liste de subversion. Mais je ne croit pas que ça soit public.
Comme c'est un grand ponte d'une boite importante, c'est peut être pas un hasard....
Espionnage industrielle ? Virus ciblé ? Complot mondial de moules linuxfrienne visant à infiltrer thalés ?
Le problème, c'est pas de packager trac, dans mon souvenir, ça tourne tout seul.
Le problème, c'est de packager clearsilver, qui possède des bindings dans 4 ou 5 languages ( java, c#, perl, python, ruby, et un module apache2 ).
Il est complet, mais pour tout faire, c'est du boulot, surtout une lib.
Et l'installation, c'est un peut le bordel, avec des appels hardcodé à #!/usr/local/bin/python...
Le vote sur les rpms est globalement suivi, car les rpms sont souvent ensuite ajouté dans contribs ( mais que contribs soit en entier sur les cds est une autre histoire, vu qu'on reste toujours limité ).On ne le voit pas directement, mais les patchs kernel comme le paquet writing sont intégrés dans le noyau ( en premier depuis plusieurs mois ).
Et le vote a aussi servi pour justifier le nouveau menu.
C'est vrai que le club, c'est plus un don à mdk et quand on le voit en tant que tel avec tout ce que mdk donne déja à coté, ça permet d'équilibrer.
La politique de mandrake depuis des années à ce sujet est clair.
On ne touche plus à la version stable sauf pour les gros bugs fixes, et les mises à jours de sécurité.
La politique du plf, est clair aussi : Intégrez les paquets libres qui ne peuvent pas être dans contribs, pour une raison X ou Y, la plupart du temps des raisons soit purement politiques ( pas d'èmulateur, pas de p2p ), soit légaux (encodeur mp3, decss et co ).
Le but n'a jamais été de proposer des backports. Le but était de rappeler aux gens que la liberté n'est pas la même partout, et d'èveilller leur conscience quant à ce genre de problème. But manifestement et à mon grand regret pas encore atteint.
Une partie du code du service pack1. C'est quasiment rien, si on pense qu'on est déja au service pack2, et qu'on a qu'un petit bout, la plupart du temps non authentifié, et difficilement compréhensible sans avoir une vu e global du noyau.
Pourquoi vouloir à tout prix commencer par démocratiser linux ?
Pourquoi ne pas simplement commencer par les applicatifs, comme openoffice, mozilla, jabber ?
Ça permettrais de garder à chacun la liberté de faire ce qu'il veut. Pourquoi être obsédé par le noyau et les applis qui tournent dessus ?
Je n'ai pas ce problème sur mes sources, mais c'est proxad en cooker.
Tu peut donner les sources exactes ( ie url ) ?
Par, le copy/paste de /etc/urpmi/urpmi.cfg ?
J'ai pas encore le droit d'activer les backdoors secrétes que le plf place dans leur paquet, donc je peut pas le lire chez toi :)
Faut aussi voir que ntfs est sorti bien avant les fs récent, et avait déja tout ou parti de ces features.
En 97, il y avait nt4 avec les acl et un journal, je sais pas si on avait ça dans le noyau linux de l'epoque ( un 2.2 ou 2.0, je pense )
Mhh, intéressant, la derniere version stable upstream est dans le cvs uniquement. Un concept ma foi assez novateurs, ne plus faire de releases, mais que ces cvs tags .
Avec une numerotation clair : 4.1 stable, 4.2 devel, d'aprés le site web, 4.3 devel car non marqué comme stable. Freshmeat aussi est à jour d'ailleurs : http://freshmeat.net/projects/rpm/(...)
> upstream en est à la version 4.3.1 et non à la version 4.2.2 .
donc fedora est l'upstream, parce d'aprés http://rpm.org/(...) :
The current latest production release is: 4.1 (ftp). RPM-4.1 made its first production release September 17, 2002.
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 )
> Je viens de vérifier et maintenant je sais. C'est toujours le même bordel.
Donc la méthode, c'est 1) tu poste 2) on te contredit, 3) tu vérifie, 4) tu sais, mais tu change pas d'avis.
Impressionnant.
> > 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).
rpm d'origine sous le controle de rh donc standard de facto. ( oui je sais, je pourrais forker, à la X.org parce que rh est trop tetus tout ça )
> Mandrake ne fait rien en automatique (selon ton url mais je
> pense que c'est une erreur).
En effet, erreur de copie. Maintenant, j'ai vu que tu sais te servir de rpm, tu aurais pu le voir par toit même. J'ai remis le fichier et pour info :
[misc@katu3 public_html] $ wc -l find-requires.*
134 find-requires.fdr
182 find-requires.mdk
Donc, plus de ligne devrait être corrélé avec plus de requires automatique, et curieusement, si quelqu'un se donne la peine de vérifier, c'est le cas.
> > 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...).
> 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 maintenir des patchs de 350 lignes, je peut te dire que c'est deja trés lourd. J'ai pas dit non maintenu, j'ai dit qu'il est non compatible avec lui même, ce que tu avoues toi même :
"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)."
De nos jours, tu ne peut plus non plus lire certains rpm trop vieux.
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.
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, ça fait beaucoup, et comme je le disait, mandrake n'est pas la seul distrib à faire ça, ce qui prouve bien que tout le monde est con sauf redhat.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Misc (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 2.
> bien !
cfdisk et fdisk redimensionne la fat ? le ntfs ? non.
Mais ça sert jamais, on va prendre un autre. Le support du lvm ?
Non plus.
Donc techniquement, ça pue.
Et oui, bien sur, il y a d'autres installeurs. Ce qui prouve bien que techniquement, celui de debian est pas assez bon.
Il y a pas que le graphique, tu saute trop vite au conclusion. Comme tout les debianneux qui n'ont plus vu ce qui se passe en face depuis des années, omnibulés par le seul truc visible de l'installation, le coté graphique.
> Et de toute facon, une Debian, ca s'installe une fois, et ca s'utilise des
> années ... Alors chipoter pour 2 heures d'installation !
J'ai jamais reinstallé ma mdk depuis la 8.2, date de la premiére install, d'un pc neuf. J'ai du faire plus de cycles d'upgrade que tu as du en faire depuis que tu utilise debian, sauf si tu utilise ça depuis la 2.0.
Toi, tu as pas eu besoin de recompiler le kernel pendant l'install debian sur un serveur pour la prise en charge du raid, comme j'ai pu voir chez certains que je connait.
L'installation 2H et on oublie, tu compte pas les 3 semaines de backports/config que tu te tapes aprés.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Misc (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à -2.
Tellement de gens qui forkent, qui refusent de suivre le projet mére, et de suivre les autres. Ensuite, on s'étonne que le projet arrivent pas à fermer tout les bugs RC...
Tellement d'installeurs alternatifs, mais beaucoup moins de remontés au niveau du vrai installeur...
Tellement de dépot alternatifs, au lieu d'aider backports.org.
Le fork a déja eu lieu.
[^] # Re: La sortie de la prochaine Debian menacée ?
Posté par Misc (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 5.
Meilleur techniquement ?
Surement pas, car sinon jamais le systême de partionnement actuel n'aurais pu passer, même avec les standards de meilleur d'il y a deux ans. Peut être avec ceux d'il y 5 ans, oui.
Meilleurs, au niveau de la liberté ?
Alors pourquoi encore supporté nonfree, si ce n'est pour satisfaire les utilisateurs ?
Meilleurs pour l'utilisateur ?
Cette mesure montre clairement que non. Enfin à part les utilisateurs qui sont contents de passer pour des gens plus intégristes que RMS et linus, et à qui on arrive à faire accepter un retard digne de microsoft, malgré un planning déja en retard, et qui sont vachement content d'apprendre que une fois de plus, l'installation debian sur certains serveurs va être reservé à une élite qui sais comment recompiler un kernel pendant l'install sur un serveur.
Ces mêmes utilisateurs qui vont s'étonner que RH vole le marché du serveur, alors que debian serait tellement mieux.
Meilleur au niveau des discussion sans fin que ça engendre ici, oui sans doute, mais je pense pas...
[^] # Re: La sortie de la prochaine Debian menacée == :)
Posté par Misc (site web personnel) . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 0.
des chiffres, des proportions ?
Tu as surement accés à des archives secrétes du nombres d'utilisateurs du libres ?
Peut être des "je voit que" ?
Trés scientifique comme méthode.
# Re: Mandrake 9.2 je te hais
Posté par Misc (site web personnel) . En réponse au journal Mandrake 9.2 je te hais. Évalué à 1.
genre, emacs, ou evim ou n'importe quoi d'autres ?
[^] # Re: Debian se vide
Posté par Misc (site web personnel) . En réponse au journal Modification du contrat social de Debian. Évalué à 0.
http://lists.debian.org/debian-devel/2004/debian-devel-200404/msg03(...)
[^] # Re: Modification du contrat social de Debian
Posté par Misc (site web personnel) . En réponse au journal Modification du contrat social de Debian. Évalué à 1.
Si debian s'en tenait à ses objectifs, sarge serait sorti sous peu. Même en s'autorisant un peu ( ~ 6 mois ) de retard, on fout pas tout en l'air 1 mois avant.
Et moi aussi, je trouve aussi que woody pue le moisi, un certain serveur dont je m'occupe est bourré de backport, on est bien obligé dés qu'on veut des features aussi révolutionnaires et unstable que postfix+sasl, clamav et un spamassassin un peu plus à jour que ce que woody propose.
Si jamais il y a encore une discussion ou un changement à faire, debian va encore retardé la distribution, et tenir en otage tout les utilisateurs de la stable ?
On tient pas compte des gens qui veulent une version stable sur leur serveur, à qui on promet depuis 1 an des "sarge va sortir bientot", des personnes qui répète ça et qui au final se retrouve un peu ridicule, du travail en plus pour un admin à qui on demande de mettre des trucs plus récents ?
j'ai rien contre le fait que debian nettoie son kernel et la doc de sa glibc car elle contient des morceaux pas assez libre pour elle.
Mais repoussé indéfiniment la release, et au final ne pas vraiment régler le probléme ( car tout le monde va finalement ajouter non-free dans le sources.list, banalisant par la même son utilisation, et rendant son éviction encore plus difficile ), c'est stupide.
La solution adopté, c'est juste pour l'apparence, une masquerade.
[^] # Re: Modification du contrat social de Debian
Posté par Misc (site web personnel) . En réponse au journal Modification du contrat social de Debian. Évalué à 1.
et il y a même un bug d'ouvert :
http://qa.mandrakesoft.com/show_bug.cgi?id=9008(...)
maintenant, la solution de mettre l'usb directement dans le kernel est pas trés propre à mon sens...
[^] # Re: Modification du contrat social de Debian
Posté par Misc (site web personnel) . En réponse au journal Modification du contrat social de Debian. Évalué à 4.
Je me permet de te citer le contrat social :
"4) Nos priorités sont nos utilisateurs et les logiciels libres"
et même :
"Les besoins de nos utilisateurs et de la communauté des logiciels libres nous guideront. Nous placerons leurs intérêts en tête de nos priorités. "
Donc satisfaire l'utilisateur doit être la priorité, non ?
( allez, jeanmi boude pas :) )
# Re: Subversion et projets importants
Posté par Misc (site web personnel) . En réponse au journal Subversion et projets importants. Évalué à 1.
[^] # Re: Windows : terrain de jeu des virus
Posté par Misc (site web personnel) . En réponse au journal Windows : terrain de jeu des virus. Évalué à 1.
Il fallait lire <ironie>
[^] # Re: Windows : terrain de jeu des virus
Posté par Misc (site web personnel) . En réponse au journal Windows : terrain de jeu des virus. Évalué à 2.
Comme c'est un grand ponte d'une boite importante, c'est peut être pas un hasard....
Espionnage industrielle ? Virus ciblé ? Complot mondial de moules linuxfrienne visant à infiltrer thalés ?
[^] # Re: Trac, un outil pour gérer des projets
Posté par Misc (site web personnel) . En réponse à la dépêche Trac, un outil pour gérer des projets. Évalué à 1.
Le problème, c'est de packager clearsilver, qui possède des bindings dans 4 ou 5 languages ( java, c#, perl, python, ruby, et un module apache2 ).
Il est complet, mais pour tout faire, c'est du boulot, surtout une lib.
Et l'installation, c'est un peut le bordel, avec des appels hardcodé à #!/usr/local/bin/python...
[^] # Re: Avis d'un utilisateur du Mandrake Club
Posté par Misc (site web personnel) . En réponse au journal Avis d'un utilisateur du Mandrake Club. Évalué à 2.
Et le vote a aussi servi pour justifier le nouveau menu.
C'est vrai que le club, c'est plus un don à mdk et quand on le voit en tant que tel avec tout ce que mdk donne déja à coté, ça permet d'équilibrer.
[^] # Re: 2 petites questions sur mandrake 10
Posté par Misc (site web personnel) . En réponse au journal 2 petites questions sur mandrake 10. Évalué à 1.
On ne touche plus à la version stable sauf pour les gros bugs fixes, et les mises à jours de sécurité.
La politique du plf, est clair aussi : Intégrez les paquets libres qui ne peuvent pas être dans contribs, pour une raison X ou Y, la plupart du temps des raisons soit purement politiques ( pas d'èmulateur, pas de p2p ), soit légaux (encodeur mp3, decss et co ).
Le but n'a jamais été de proposer des backports. Le but était de rappeler aux gens que la liberté n'est pas la même partout, et d'èveilller leur conscience quant à ce genre de problème. But manifestement et à mon grand regret pas encore atteint.
[^] # Re: Comment vraiment démocratiser linux ?
Posté par Misc (site web personnel) . En réponse au journal Comment vraiment démocratiser linux ?. Évalué à 1.
# Re: Comment vraiment démocratiser linux ?
Posté par Misc (site web personnel) . En réponse au journal Comment vraiment démocratiser linux ?. Évalué à 1.
Pourquoi ne pas simplement commencer par les applicatifs, comme openoffice, mozilla, jabber ?
Ça permettrais de garder à chacun la liberté de faire ce qu'il veut. Pourquoi être obsédé par le noyau et les applis qui tournent dessus ?
# Re: Trac, un outil pour gérer des projets
Posté par Misc (site web personnel) . En réponse à la dépêche Trac, un outil pour gérer des projets. Évalué à 3.
Je serais intéressé par des retours, si jamais il y a des trucs qui marche pas, ou qui pourrait être amélioré.
# Re: Mandrake 10.0 && urpmi.update -a
Posté par Misc (site web personnel) . En réponse au journal Mandrake 10.0 && urpmi.update -a. Évalué à 1.
Tu peut donner les sources exactes ( ie url ) ?
Par, le copy/paste de /etc/urpmi/urpmi.cfg ?
J'ai pas encore le droit d'activer les backdoors secrétes que le plf place dans leur paquet, donc je peut pas le lire chez toi :)
[^] # Re: Forks libres de RedHat Enterprise Linux
Posté par Misc (site web personnel) . En réponse à la dépêche Forks libres de RedHat Enterprise Linux. Évalué à 1.
Alors que nos profs se vantait de pouvoir lancé oracle avec 32 Mo, assez pour tester et faire du pl/sql...
[^] # Re: grep grippe
Posté par Misc (site web personnel) . En réponse au journal grep grippe. Évalué à 1.
utilisez alias pour voir les alias, et désactivez l'alias temporairement via
\grep, ou /bin/grep
[^] # Re: Quid de la stabilité ?
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 1.
En 97, il y avait nt4 avec les acl et un journal, je sais pas si on avait ça dans le noyau linux de l'epoque ( un 2.2 ou 2.0, je pense )
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 3.
> ftp://ftp.proxad.net/pub/Distributions_Linux/Mandrakelinux/old/7.2(...))
Impressionnant. Je donne un exemple de fichier qui marche pas, tu en prends un autre, qui marche, et voila. Positivement epaté.
Celui la marche, en effet :
/tmp $ wget -q ftp://ftp.proxad.net/pub/Distributions_Linux/Mandrakelinux/old/7.(...) 2/SRPMS/heartbeat-0.4.8-3mdk.src.rpm && rpm -qpl heartbeat-0.4.8-3mdk.src.rpm
authkeys
ha.cf
haresources
heartbeat-0.4.8.tar.bz2
heartbeat.spec
ldirectord-init.patch
www.cf
/tmp $ file heartbeat-0.4.8-3mdk.src.rpm; rpm -v | head -n 1
heartbeat-0.4.8-3mdk.src.rpm: RPM v3 src i386 heartbeat-0.4.8-3mdk
RPM version 4.2.2
/tmp $
Celui qui marche pas, c'est le fichier la :
http://katu3.zarb.org/~misc/heartbeat-0.4.9-1mdk.src.rpm(...)
Il vient du reprtoire 8.2 ( donc il y a moins de temps que la sortie de windows XP, ce qui fait pas vieux pour une incompatibilité )
> Ben il faut taper dans le CVS : http://www.rpm.org/cvs_help/(...(...))
Mhh, intéressant, la derniere version stable upstream est dans le cvs uniquement. Un concept ma foi assez novateurs, ne plus faire de releases, mais que ces cvs tags .
Avec une numerotation clair : 4.1 stable, 4.2 devel, d'aprés le site web, 4.3 devel car non marqué comme stable. Freshmeat aussi est à jour d'ailleurs :
http://freshmeat.net/projects/rpm/(...)
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 2.
> Exemple ?
[misc@kenobi SRPMS] $ rpm -qpl heartbeat-0.4.9-1mdk.src.rpm
error: heartbeat-0.4.9-1mdk.src.rpm: rpmReadSignature failed: region trailer: BAD, tag 61 type 7 offset 64 count 16
[misc@kenobi SRPMS] $ rpm4.0.4 -qpl heartbeat-0.4.9-1mdk.src.rpm
authkeys
ha.cf
haresources
heartbeat-0.4.9.tar.bz2
heartbeat-init.patch
heartbeat-time.patch
heartbeat.spec
ldirectord-init.patch
www.cf
[misc@kenobi SRPMS] $ rpm -v | head -n 1
RPM version 4.2
[misc@kenobi SRPMS] $ file heartbeat-0.4.9-1mdk.src.rpm
heartbeat-0.4.9-1mdk.src.rpm: RPM v3 src i386 heartbeat-0.4.9-1mdk
> upstream en est à la version 4.3.1 et non à la version 4.2.2 .
donc fedora est l'upstream, parce d'aprés http://rpm.org/(...) :
The current latest production release is: 4.1 (ftp). RPM-4.1 made its first production release September 17, 2002.
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 )
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 2.
Donc la méthode, c'est 1) tu poste 2) on te contredit, 3) tu vérifie, 4) tu sais, mais tu change pas d'avis.
Impressionnant.
> > 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).
rpm d'origine sous le controle de rh donc standard de facto. ( oui je sais, je pourrais forker, à la X.org parce que rh est trop tetus tout ça )
> Mandrake ne fait rien en automatique (selon ton url mais je
> pense que c'est une erreur).
En effet, erreur de copie. Maintenant, j'ai vu que tu sais te servir de rpm, tu aurais pu le voir par toit même. J'ai remis le fichier et pour info :
[misc@katu3 public_html] $ wc -l find-requires.*
134 find-requires.fdr
182 find-requires.mdk
Donc, plus de ligne devrait être corrélé avec plus de requires automatique, et curieusement, si quelqu'un se donne la peine de vérifier, c'est le cas.
> > 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...).
Non, on parle de dependances du type : 'devel(libGl)'
http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmDevelDependencies(...)
> 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 maintenir des patchs de 350 lignes, je peut te dire que c'est deja trés lourd. J'ai pas dit non maintenu, j'ai dit qu'il est non compatible avec lui même, ce que tu avoues toi même :
"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)."
De nos jours, tu ne peut plus non plus lire certains rpm trop vieux.
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.
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, ça fait beaucoup, et comme je le disait, mandrake n'est pas la seul distrib à faire ça, ce qui prouve bien que tout le monde est con sauf redhat.