non, non. Je viens de regarder dans votre repository, vous avez toujours
un port qui s'appelle kdelibs3, et un autre qui s'appelle kdelibs3-nocups...
et il y en a bien sur d'autres. Le mecanisme `MASTERDIR' multiplie le
nombre de ports de maniere assez artificielle.
Tu peux toujours pr?senter ?a comme tu veux, mais 5000 c'est pitoyable ?
l'heure actuelle.
Ca ne veut rien dire. Tu n'avances pas le moindre argument concret, comme
des exemples d'appli qui n'y sont pas.
Et je ne serais pas ?tonn? que le core OS rende le
port de nombreux logiciels modernes tr?s probl?matique pour des raisons
de non support d'appels syst?mes r?cemment introduit sous Linux.
Vas-y, donne des exemples...
Suivre le rythme pour le `plaisir' de suivre le rythme ne sert a rien.
A cote de ca, je te rappelle quand meme que les buts d'OpenBSD, ce
n'est pas de dominer le monde, mais d'avoir un systeme sans souci,
avec les applis dont NOUS avons besoin (nous = la communaute OpenBSD).
Si des gens se pointent avec des besoins specifiques, et demandent
certaines applis, il est fort probable qu'on les aidera, et qu'on portera
les applis en question...
non, non. Je viens de regarder dans votre repository, vous avez toujours
un port qui s'appelle kdelibs3, et un autre qui s'appelle kdelibs3-nocups...
et il y en a bien sur d'autres. Le mecanisme `MASTERDIR' multiplie le
nombre de ports de maniere assez artificielle.
Tu peux toujours pr?senter ?a comme tu veux, mais 5000 c'est pitoyable ?
l'heure actuelle.
Ca ne veut rien dire. Tu n'avances pas le moindre argument concret, comme
des exemples d'appli qui n'y sont pas.
Et je ne serais pas ?tonn? que le core OS rende le
port de nombreux logiciels modernes tr?s probl?matique pour des raisons
de non support d'appels syst?mes r?cemment introduit sous Linux.
Vas-y, donne des exemples...
Suivre le rythme pour le `plaisir' de suivre le rythme ne sert a rien.
A cote de ca, je te rappelle quand meme que les buts d'OpenBSD, ce
n'est pas de dominer le monde, mais d'avoir un systeme sans souci,
avec les applis dont NOUS avons besoin (nous = la communaute OpenBSD).
Si des gens se pointent avec des besoins specifiques, et demandent
certaines applis, il est fort probable qu'on les aidera, et qu'on portera
les applis en question...
non, non. Je viens de regarder dans votre repository, vous avez toujours
un port qui s'appelle kdelibs3, et un autre qui s'appelle kdelibs3-nocups...
et il y en a bien sur d'autres. Le mecanisme `MASTERDIR' multiplie le
nombre de ports de maniere assez artificielle.
Tu peux toujours pr?senter ?a comme tu veux, mais 5000 c'est pitoyable ?
l'heure actuelle.
Ca ne veut rien dire. Tu n'avances pas le moindre argument concret, comme
des exemples d'appli qui n'y sont pas.
Et je ne serais pas ?tonn? que le core OS rende le
port de nombreux logiciels modernes tr?s probl?matique pour des raisons
de non support d'appels syst?mes r?cemment introduit sous Linux.
Vas-y, donne des exemples...
Suivre le rythme pour le `plaisir' de suivre le rythme ne sert a rien.
A cote de ca, je te rappelle quand meme que les buts d'OpenBSD, ce
n'est pas de dominer le monde, mais d'avoir un systeme sans souci,
avec les applis dont NOUS avons besoin (nous = la communaute OpenBSD).
Si des gens se pointent avec des besoins specifiques, et demandent
certaines applis, il est fort probable qu'on les aidera, et qu'on portera
les applis en question...
Par exemple, une appli que je trouve utile k9copy (un clone de
dvdshrink), je ne le trouve pas dans la liste des paquets de Open 4.2,
je ne vois pas non plus sbcl, cmucl, django, ... mais de tels exemples
seront toujours anecdotiques, tandis que le rapport 17000/5000 n'est pas
anecdotique, il est massif.
J'ai regardé ici:
http://www.openbsd.org/4.2_packages/i386.html
Pour ce qui est de Java je ne sais pas ce qu'il en est, et donc pour les
dépendances de Java.
Tout ce qui est multithreadé par exemple.
Tu crois sincèrement que les gens vont faire l'effort de demander des
applis et d'attendre qu'elles arrivent quand ils trouvent ailleurs des
choses où tout fonctionne, avec des performances sans commune mesure,
et avec moins de risque de se trouver dans un cul de sac? Tu vis
chez Mickey, toi.
Par exemple, une appli que je trouve utile k9copy (un clone de
dvdshrink), je ne le trouve pas dans la liste des paquets de Open 4.2,
je ne vois pas non plus sbcl, cmucl, django, ... mais de tels exemples
seront toujours anecdotiques, tandis que le rapport 17000/5000 n'est pas
anecdotique, il est massif.
J'ai regardé ici:
http://www.openbsd.org/4.2_packages/i386.html
Pour ce qui est de Java je ne sais pas ce qu'il en est, et donc pour les
dépendances de Java.
Tout ce qui est multithreadé par exemple.
Tu crois sincèrement que les gens vont faire l'effort de demander des
applis et d'attendre qu'elles arrivent quand ils trouvent ailleurs des
choses où tout fonctionne, avec des performances sans commune mesure,
et avec moins de risque de se trouver dans un cul de sac? Tu vis
chez Mickey, toi.
Par exemple, une appli que je trouve utile k9copy (un clone de
dvdshrink), je ne le trouve pas dans la liste des paquets de Open 4.2,
je ne vois pas non plus sbcl, cmucl, django, ... mais de tels exemples
seront toujours anecdotiques, tandis que le rapport 17000/5000 n'est pas
anecdotique, il est massif.
J'ai regardé ici:
http://www.openbsd.org/4.2_packages/i386.html
Pour ce qui est de Java je ne sais pas ce qu'il en est, et donc pour les
dépendances de Java.
Tout ce qui est multithreadé par exemple.
Tu crois sincèrement que les gens vont faire l'effort de demander des
applis et d'attendre qu'elles arrivent quand ils trouvent ailleurs des
choses où tout fonctionne, avec des performances sans commune mesure,
et avec moins de risque de se trouver dans un cul de sac? Tu vis
chez Mickey, toi.
Pour ce qui est de java, on est pour l'instant toujours coinces par la
licence de sun en ce qui concerne la redistribution de packages binaires.
Ca va changer lorsqu'il y aura suffisamment du toolkit `libere' pour pouvoir
en faire un package fonctionnel...
mais on a des ports de jdk 1.3 -> 1.7... c'est entre autres utilise par
openoffice, netbeans, et eclipse, de memoire...Tout ce qui est multithread? par exemple.
Pas de probleme lie aux appels systemes, en l'occurrence. D'autres problemes
lies au modele sous-jacent...
Pour ce qui est de java, on est pour l'instant toujours coinces par la
licence de sun en ce qui concerne la redistribution de packages binaires.
Ca va changer lorsqu'il y aura suffisamment du toolkit `libere' pour pouvoir
en faire un package fonctionnel...
mais on a des ports de jdk 1.3 -> 1.7... c'est entre autres utilise par
openoffice, netbeans, et eclipse, de memoire...
Tout ce qui est multithread? par exemple.
Pas de probleme lie aux appels systemes, en l'occurrence. D'autres problemes
lies au modele sous-jacent...
Pour ce qui est de java, on est pour l'instant toujours coinces par la
licence de sun en ce qui concerne la redistribution de packages binaires.
Ca va changer lorsqu'il y aura suffisamment du toolkit `libere' pour pouvoir
en faire un package fonctionnel...
mais on a des ports de jdk 1.3 -> 1.7... c'est entre autres utilise par
openoffice, netbeans, et eclipse, de memoire...Tout ce qui est multithread? par exemple.
Pas de probleme lie aux appels systemes, en l'occurrence. D'autres problemes
lies au modele sous-jacent...
C'est pour ça que mon NetBSD n'est plus mis à jour depuis un bail, ça me
fait trop chier.
Pareil pour moi. Je ne me sens pas une âme à recompiler tous mes ports
tous les jours comme les maniaques de portupgrade ou portmaster. Donc
j'attends la sortie de 7.0 pour tout réinstaller en bloc avec les
binaires de la release. C'est de loin la solution la plus fiable et
qui fait perdre le moins de temps.
En conclusion, les systèmes Debian-like sont à des années lumière en
avant des *BSD en ce qui concerne la facilité de mise à jour (
excepté peut être OpenBSD, mais là la pauvreté de l'offre de ports est
tellement évidente que ça fait presque pleurer).
C'est pour ça que mon NetBSD n'est plus mis à jour depuis un bail, ça me
fait trop chier.
Pareil pour moi. Je ne me sens pas une âme à recompiler tous mes ports
tous les jours comme les maniaques de portupgrade ou portmaster. Donc
j'attends la sortie de 7.0 pour tout réinstaller en bloc avec les
binaires de la release. C'est de loin la solution la plus fiable et
qui fait perdre le moins de temps.
En conclusion, les systèmes Debian-like sont à des années lumière en
avant des *BSD en ce qui concerne la facilité de mise à jour (
excepté peut être OpenBSD, mais là la pauvreté de l'offre de ports est
tellement évidente que ça fait presque pleurer).
C'est pour ça que mon NetBSD n'est plus mis à jour depuis un bail, ça me
fait trop chier.
Pareil pour moi. Je ne me sens pas une âme à recompiler tous mes ports
tous les jours comme les maniaques de portupgrade ou portmaster. Donc
j'attends la sortie de 7.0 pour tout réinstaller en bloc avec les
binaires de la release. C'est de loin la solution la plus fiable et
qui fait perdre le moins de temps.
En conclusion, les systèmes Debian-like sont à des années lumière en
avant des *BSD en ce qui concerne la facilité de mise à jour (
excepté peut être OpenBSD, mais là la pauvreté de l'offre de ports est
tellement évidente que ça fait presque pleurer).
Mis à part le problème de lenteur déjà évoqué, et qui n'est pas une
fatalité (il y a des travaux en cours, surtout depuis que l'éclatement
de X en multiples sous-ports a révélé où ce trouvait les principaux
points de blocages), le problème principal de portupgrade pour celui qui
veut utiliser les paquets binaires est le décalage entre la mise à jour
de l'arbre des ports (récupéré par cvsup ou Portsnap) et la
disponibilité des packages. Actuellement, pour i386 et amd64, c'est de
l'ordre de 2 ou 3 jours en moyenne, et ça peut être un peu plus en cas
de mise à jour de Gnome, KDE ou X.
Et pour faciliter la manip', il y a une idée simple qui devrait être
mise en place bientôt : c'est de conserver l'arbre des ports ayant
servi à générer un lots de paquets avec les paquets eux-mêmes, ce qui
permet d'avoir un ensemble cohérent, y compris pour les ports non
packageables.
Mis à part le problème de lenteur déjà évoqué, et qui n'est pas une
fatalité (il y a des travaux en cours, surtout depuis que l'éclatement
de X en multiples sous-ports a révélé où ce trouvait les principaux
points de blocages), le problème principal de portupgrade pour celui qui
veut utiliser les paquets binaires est le décalage entre la mise à jour
de l'arbre des ports (récupéré par cvsup ou Portsnap) et la
disponibilité des packages. Actuellement, pour i386 et amd64, c'est de
l'ordre de 2 ou 3 jours en moyenne, et ça peut être un peu plus en cas
de mise à jour de Gnome, KDE ou X.
Et pour faciliter la manip', il y a une idée simple qui devrait être
mise en place bientôt : c'est de conserver l'arbre des ports ayant
servi à générer un lots de paquets avec les paquets eux-mêmes, ce qui
permet d'avoir un ensemble cohérent, y compris pour les ports non
packageables.
Mis à part le problème de lenteur déjà évoqué, et qui n'est pas une
fatalité (il y a des travaux en cours, surtout depuis que l'éclatement
de X en multiples sous-ports a révélé où ce trouvait les principaux
points de blocages), le problème principal de portupgrade pour celui qui
veut utiliser les paquets binaires est le décalage entre la mise à jour
de l'arbre des ports (récupéré par cvsup ou Portsnap) et la
disponibilité des packages. Actuellement, pour i386 et amd64, c'est de
l'ordre de 2 ou 3 jours en moyenne, et ça peut être un peu plus en cas
de mise à jour de Gnome, KDE ou X.
Et pour faciliter la manip', il y a une idée simple qui devrait être
mise en place bientôt : c'est de conserver l'arbre des ports ayant
servi à générer un lots de paquets avec les paquets eux-mêmes, ce qui
permet d'avoir un ensemble cohérent, y compris pour les ports non
packageables.
Deux ou trois jours ou une semaine ou un mois ça ne me poserait aucun
problème s'il y avait une infrastructure quelconque permettant de
s'assurer que la mise à jour va fonctionner. Or il n'y en a aucune,
seuls les RELEASE sont des points fixes fiables. En ce qui concerne les
problèmes de lenteur, pour pkg_add je crois que ça a été bien amélioré,
mais pour portupgrade je n'en crois rien. Il se trouve que j'ai lu tout
le code source de portupgrade du début à la fin, et je ne crois pas
du tout qu'il soit améliorable. Aucun des choix qui ont été faits ne se
sont préoccupés une seconde de la performance. Par là dessus, il y a des
passages où le programme lit dans le marc de café pour savoir quoi
faire, avec des résultats qui peuvent bien évidemment être désastreux.
Et enfin l'infrastructure des ports telle qu'elle est ne permet tout
simplement pas de résoudre le problème posé par un upgrade sans
upgrader massivement tous les ports, ce qui fait que les gens
préconisent portupgrade -a ou portmaster. A mon avis ces solutions sont
peut être adaptées pour un serveur qui a 20 ports installés, mais sont
une guignolade pour un desktop avec 1000 ports installés. Le problème
de est qu'il est parasité par des admin sys
qui ont une vision purement orientée "serveur" du problème. Donc
je n'ai aucun espoir que la situation s'améliore. Ces gens mettent
la tête dans le sable.
Deux ou trois jours ou une semaine ou un mois ça ne me poserait aucun
problème s'il y avait une infrastructure quelconque permettant de
s'assurer que la mise à jour va fonctionner. Or il n'y en a aucune,
seuls les RELEASE sont des points fixes fiables. En ce qui concerne les
problèmes de lenteur, pour pkg_add je crois que ça a été bien amélioré,
mais pour portupgrade je n'en crois rien. Il se trouve que j'ai lu tout
le code source de portupgrade du début à la fin, et je ne crois pas
du tout qu'il soit améliorable. Aucun des choix qui ont été faits ne se
sont préoccupés une seconde de la performance. Par là dessus, il y a des
passages où le programme lit dans le marc de café pour savoir quoi
faire, avec des résultats qui peuvent bien évidemment être désastreux.
Et enfin l'infrastructure des ports telle qu'elle est ne permet tout
simplement pas de résoudre le problème posé par un upgrade sans
upgrader massivement tous les ports, ce qui fait que les gens
préconisent portupgrade -a ou portmaster. A mon avis ces solutions sont
peut être adaptées pour un serveur qui a 20 ports installés, mais sont
une guignolade pour un desktop avec 1000 ports installés. Le problème
de freebsd-ports@freebsd.org est qu'il est parasité par des admin sys
qui ont une vision purement orientée "serveur" du problème. Donc
je n'ai aucun espoir que la situation s'améliore. Ces gens mettent
la tête dans le sable.
Deux ou trois jours ou une semaine ou un mois ça ne me poserait aucun
problème s'il y avait une infrastructure quelconque permettant de
s'assurer que la mise à jour va fonctionner. Or il n'y en a aucune,
seuls les RELEASE sont des points fixes fiables. En ce qui concerne les
problèmes de lenteur, pour pkg_add je crois que ça a été bien amélioré,
mais pour portupgrade je n'en crois rien. Il se trouve que j'ai lu tout
le code source de portupgrade du début à la fin, et je ne crois pas
du tout qu'il soit améliorable. Aucun des choix qui ont été faits ne se
sont préoccupés une seconde de la performance. Par là dessus, il y a des
passages où le programme lit dans le marc de café pour savoir quoi
faire, avec des résultats qui peuvent bien évidemment être désastreux.
Et enfin l'infrastructure des ports telle qu'elle est ne permet tout
simplement pas de résoudre le problème posé par un upgrade sans
upgrader massivement tous les ports, ce qui fait que les gens
préconisent portupgrade -a ou portmaster. A mon avis ces solutions sont
peut être adaptées pour un serveur qui a 20 ports installés, mais sont
une guignolade pour un desktop avec 1000 ports installés. Le problème
de est qu'il est parasité par des admin sys
qui ont une vision purement orientée "serveur" du problème. Donc
je n'ai aucun espoir que la situation s'améliore. Ces gens mettent
la tête dans le sable.
Samedi 08 décembre 2007 à 19:58 GMT, Michel Talon a écrit :
J'avoue n'avoir pas lu le code de portupgrade, mais je n'ai jamais eu de
résultats désastreux. C'est peut-être dû au fait que j'utilise
systématiquement l'option -R, qui met à jour également les dépendances
utilisées s'il le faut.
`portupgrade -a' ne met à jour que les ports qui doivent l'être (sauf si
on ajoute -f pour forcer la mise à jour de tout !),
Samedi 08 décembre 2007 à 19:58 GMT, Michel Talon a écrit :
J'avoue n'avoir pas lu le code de portupgrade, mais je n'ai jamais eu de
résultats désastreux. C'est peut-être dû au fait que j'utilise
systématiquement l'option -R, qui met à jour également les dépendances
utilisées s'il le faut.
`portupgrade -a' ne met à jour que les ports qui doivent l'être (sauf si
on ajoute -f pour forcer la mise à jour de tout !),
Samedi 08 décembre 2007 à 19:58 GMT, Michel Talon a écrit :
J'avoue n'avoir pas lu le code de portupgrade, mais je n'ai jamais eu de
résultats désastreux. C'est peut-être dû au fait que j'utilise
systématiquement l'option -R, qui met à jour également les dépendances
utilisées s'il le faut.
`portupgrade -a' ne met à jour que les ports qui doivent l'être (sauf si
on ajoute -f pour forcer la mise à jour de tout !),
Deux ou trois jours ou une semaine ou un mois ça ne me poserait aucun
problème s'il y avait une infrastructure quelconque permettant de
s'assurer que la mise à jour va fonctionner.
Deux ou trois jours ou une semaine ou un mois ça ne me poserait aucun
problème s'il y avait une infrastructure quelconque permettant de
s'assurer que la mise à jour va fonctionner.
Deux ou trois jours ou une semaine ou un mois ça ne me poserait aucun
problème s'il y avait une infrastructure quelconque permettant de
s'assurer que la mise à jour va fonctionner.
L'un des endroits les plus scabreux est ce qui se passe quand un port a
disparu et a été remplacé par un autre. Portupgrade soit demande à
l'opérateur le nom du nouveau port (et il est évident qu'il a 90% de
chances de se planter) soit il va chercher la pythie pour inventer ce
nom. J'ai déjà vu des cas particulièrement cocasses. Je suis à peu près
sûr que dans le cas d'une installation typique de M. Lambda (et non pas
d'un développeur FreeBSD comme toi) le pkgdb se trouve rapidement faux
dans les grandes largeurs, et donc que pkgupgrade n'a plus qu'une vision
fantaisiste des dépendances.
résultats désastreux. C'est peut-être dû au fait que j'utilise
systématiquement l'option -R, qui met à jour également les dépendances
utilisées s'il le faut.
Donc supposons que tu mettes à jour un paquet A qui, grace à -R te met
à jour gettext, te faisant ainsi un enfant dans le dos. Crois tu que ça ne
va pas avoir quelques répercussions fâcheuses ailleurs? (Bon j'admets
qu'une copie de sauvegarde est effectuée). En fait dans bien des cas
-r serait autrement plus utile que -R. Mais alors si tu regardes toutes
les dépendances vers le haut et le bas, dans une installation typique,
tu upgrades absolument tout.
`portupgrade -a' ne met à jour que les ports qui doivent l'être (sauf si
on ajoute -f pour forcer la mise à jour de tout !),
Le problème étant le fait que le caractère "à jour" d'un paquet n'est
pas forcément visible dans son numéro de version, ce qui rend, comme je
le disais l'upgrade insoluble. Par exemple à cause des modifications
de la libc. Là encore les symboles versionnés de FreeBSD-7 vont aider
à résoudre cette question.
L'un des endroits les plus scabreux est ce qui se passe quand un port a
disparu et a été remplacé par un autre. Portupgrade soit demande à
l'opérateur le nom du nouveau port (et il est évident qu'il a 90% de
chances de se planter) soit il va chercher la pythie pour inventer ce
nom. J'ai déjà vu des cas particulièrement cocasses. Je suis à peu près
sûr que dans le cas d'une installation typique de M. Lambda (et non pas
d'un développeur FreeBSD comme toi) le pkgdb se trouve rapidement faux
dans les grandes largeurs, et donc que pkgupgrade n'a plus qu'une vision
fantaisiste des dépendances.
résultats désastreux. C'est peut-être dû au fait que j'utilise
systématiquement l'option -R, qui met à jour également les dépendances
utilisées s'il le faut.
Donc supposons que tu mettes à jour un paquet A qui, grace à -R te met
à jour gettext, te faisant ainsi un enfant dans le dos. Crois tu que ça ne
va pas avoir quelques répercussions fâcheuses ailleurs? (Bon j'admets
qu'une copie de sauvegarde est effectuée). En fait dans bien des cas
-r serait autrement plus utile que -R. Mais alors si tu regardes toutes
les dépendances vers le haut et le bas, dans une installation typique,
tu upgrades absolument tout.
`portupgrade -a' ne met à jour que les ports qui doivent l'être (sauf si
on ajoute -f pour forcer la mise à jour de tout !),
Le problème étant le fait que le caractère "à jour" d'un paquet n'est
pas forcément visible dans son numéro de version, ce qui rend, comme je
le disais l'upgrade insoluble. Par exemple à cause des modifications
de la libc. Là encore les symboles versionnés de FreeBSD-7 vont aider
à résoudre cette question.
L'un des endroits les plus scabreux est ce qui se passe quand un port a
disparu et a été remplacé par un autre. Portupgrade soit demande à
l'opérateur le nom du nouveau port (et il est évident qu'il a 90% de
chances de se planter) soit il va chercher la pythie pour inventer ce
nom. J'ai déjà vu des cas particulièrement cocasses. Je suis à peu près
sûr que dans le cas d'une installation typique de M. Lambda (et non pas
d'un développeur FreeBSD comme toi) le pkgdb se trouve rapidement faux
dans les grandes largeurs, et donc que pkgupgrade n'a plus qu'une vision
fantaisiste des dépendances.
résultats désastreux. C'est peut-être dû au fait que j'utilise
systématiquement l'option -R, qui met à jour également les dépendances
utilisées s'il le faut.
Donc supposons que tu mettes à jour un paquet A qui, grace à -R te met
à jour gettext, te faisant ainsi un enfant dans le dos. Crois tu que ça ne
va pas avoir quelques répercussions fâcheuses ailleurs? (Bon j'admets
qu'une copie de sauvegarde est effectuée). En fait dans bien des cas
-r serait autrement plus utile que -R. Mais alors si tu regardes toutes
les dépendances vers le haut et le bas, dans une installation typique,
tu upgrades absolument tout.
`portupgrade -a' ne met à jour que les ports qui doivent l'être (sauf si
on ajoute -f pour forcer la mise à jour de tout !),
Le problème étant le fait que le caractère "à jour" d'un paquet n'est
pas forcément visible dans son numéro de version, ce qui rend, comme je
le disais l'upgrade insoluble. Par exemple à cause des modifications
de la libc. Là encore les symboles versionnés de FreeBSD-7 vont aider
à résoudre cette question.
Ça peut arriver si on panache des mises à jours manuelles (make
deinstall / reinstall) et des portupgrade, ou dans les cas où il y a
plusieurs versions d'un même port (ex. MySQL) et qu'on n'utilise pas la
version par défaut *et* qu'on n'a pas indiqué quelle version on voulait
dans ALT_PKGDEP de pkgtools.conf. Mais il me semble que dans ces cas là
tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes
être un peu long...
Ça peut arriver si on panache des mises à jours manuelles (make
deinstall / reinstall) et des portupgrade, ou dans les cas où il y a
plusieurs versions d'un même port (ex. MySQL) et qu'on n'utilise pas la
version par défaut *et* qu'on n'a pas indiqué quelle version on voulait
dans ALT_PKGDEP de pkgtools.conf. Mais il me semble que dans ces cas là
tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes
être un peu long...
Ça peut arriver si on panache des mises à jours manuelles (make
deinstall / reinstall) et des portupgrade, ou dans les cas où il y a
plusieurs versions d'un même port (ex. MySQL) et qu'on n'utilise pas la
version par défaut *et* qu'on n'a pas indiqué quelle version on voulait
dans ALT_PKGDEP de pkgtools.conf. Mais il me semble que dans ces cas là
tout rentre dans l'ordre après un `pkgdb -F' interactif, qui peut certes
être un peu long...