Bonsoir,

Je ne souhaite virer les ports relatifs aux langues étrangères.

Je mets donc ce qu'il faut dans /usr/local/etc/pkgtools.conf

IGNORE_CATEGORIES = [
'chinese',
'german',
'hebrew',
'japanese',
'korean',
'polish',
'portuguese',
'russian',
'ukrainian',
'vietnamese',
]

et exécute portsdb -Ufu comme indiqué.

Seulement... qu'est-ce que c'est sensé faire ?

En effet, si INDEX est bien reconstruit, les ports que je voulais virer
sont toujours là, dans INDEX, et dans l'arborescence de /usr/ports.

Un truc m'échappe, là.


Merci.

--
Fred.

fred :

> En effet, si INDEX est bien reconstruit, les ports que je voulais
> virer sont toujours là, dans INDEX, et dans l'arborescence de
> /usr/ports.

portupgrade ne manipule pas l'arbre des ports, si tu veux ne pas
récupérer une partie de l'arbre, il faut le spécifier dans le supfile
si tu utilises cvsup. C'est plutôt déconseillé il me semble.

--
http://www.lamaiziere.net/logiciels.html

Patrick Lamaizière <adresse@est.invalid> a écrit :

> fred :
>
>> En effet, si INDEX est bien reconstruit, les ports que je voulais
>> virer sont toujours là, dans INDEX, et dans l'arborescence de
>> /usr/ports.
>
> portupgrade ne manipule pas l'arbre des ports, si tu veux ne pas
Je pensais au moins l'INDEX.

> récupérer une partie de l'arbre, il faut le spécifier dans le supfile
> si tu utilises cvsup. C'est plutôt déconseillé il me semble.
Ok... alors je n'ai pas compris à quoi servait le IGNORE_CATEGORIES de
/usr/local/etc/pkgtools.conf :-(

# IGNORE_CATEGORIES: array
#
# This is a list of port categories you want the pkgtools to ignore.
# Typically you want to list language specific categories of the
# languages you don't use.
#
# After configuring this list, you need to rebuild the ports
# database to reflect the changes. (run 'portsdb -Ufu')
#


--
Fred.

On Wed, 29 Nov 2006 01:30:03 +0100
fred <fredantispam@free.fr> wrote:

> Ok... alors je n'ai pas compris à quoi servait le IGNORE_CATEGORIES de
> /usr/local/etc/pkgtools.conf :-(

les pkgtools (portupgrade et tout ce qui vient avec) sont des outils
externes au système de ports, ils gèrent leur propre index et ne
modifient rien dans l'arbre des ports (en tout cas pas plus que ce que
pourrait faire make all, make clean ou make distclean.)

La modifie que tu as faite doit impacter la mise à jour, l'installation
et la recherche de ports pour les commandes
portupgrade/portinstall/portversion ...

--
A quand des images débiles sur MultiDeskOS ?
-- Jayce - 42 --

Patrick Lamaizière <adresse@est.invalid> wrote:
> fred :
>
> > En effet, si INDEX est bien reconstruit, les ports que je voulais
> > virer sont toujours là, dans INDEX, et dans l'arborescence de
> > /usr/ports.
>
> portupgrade ne manipule pas l'arbre des ports, si tu veux ne pas
> récupérer une partie de l'arbre, il faut le spécifier dans le supfile
> si tu utilises cvsup. C'est plutôt déconseillé il me semble.
>

C'est à dire que des outils comme "make index" descendent dans l'arbre
des ports sans discrimination, et plantent quand on en a supprimé une
partie. C'est une des choses auxquelles j'ai fait attention dans mon
propre script. En fait le but de mon script, c'est -tu lui donnes une
collection arbitraire de ports- il te donne l'index correspondant. La
collection arbitraire ce serait naturellement tous les ports installés.
Sur ma machine, P4 3Ghz un peu vieille ça met 1/10 de seconde par port,
donc pour 600 ports installés, ce qui me semble quelque chose de
raisonnable, il faut compter une minute pour fabriquer cet index. J'ai
essayé sur un Core 2 Duo, ça va 3 fois plus vite, donc 20s seulement!
Ce qu'il faut que je fasse, c'est introduire une fonction de
"fermeture", quand il est détecté qu'une dépendance n'est pas dans la
collection, la rajouter à la collection et donc à l'index. Une fois ça
fait, l'index officiel ne sert plus à rien, ni la base de données de
portupgrade (INDEX.db). A vrai dire d'ailleurs je trouve que ces bases
de données Berkeley, INDEX.db et pkgdb.db ne servent à rien sinon à
ralentir considérablement toutes les opérations, vu que l'ensemble de
leur contenu tient très aisément en mémoire pour un traîtement d'une
rapidité sans commune mesure: quand mon script a l'index totalement
chargé en mémoire pour 16000 ports, il fait 20 mégas, ce qui est
totalement négligeable à l'heure actuelle. Et si le but est simplement
de sauvegarder l'état de la mémoire sur disque, utiliser cPickle de
python prend moins d'une seconde pour écrire ou lire la totalité de ces
données. Et en ce qui concerne la rapidité des opérations en mémoire, le
script python prend quelque chose comme 2s pour obtenir le "topological
sorting" des 16000 ports, à comparer au temps perdu infini par
portupgrade. Bref on peut envisager sereinement de faire la même chose
que apt-get dist-upgrade sans bénéficier de l'infrastructure des dépôts
Debian, mais dans un temps tout à fait comparable, et non pas en y
passant des heures comme fait portupgrade.



--

Michel TALON

Michel Talon :

[...]

> mais dans un
> temps tout à fait comparable, et non pas en y passant des heures comme
> fait portupgrade.

Ben je ne pige pas trop, ton script devrait être plus rapide que
portsdb -U pour construire l'index ?

# /usr/bin/time -h portsdb -U
Updating the ports index ... Generating INDEX.tmp - please
21m37,03s real 16m4,14s user 3m21,52s sys

# /usr/bin/time -h ./build_index.py
.......accessibility......
Total time spent: 26 minutes 27 seconds.
You will find the generated index in INDEX and the errors
encountered in ErrorLog.
26m28,23s real 18m0,15s user 6m48,05s sys

--
http://www.lamaiziere.net/logiciels.html

Patrick Lamaizière <adresse@est.invalid> wrote:
> Michel Talon :
>
> [...]
>
> > mais dans un
> > temps tout à fait comparable, et non pas en y passant des heures comme
> > fait portupgrade.
>
> Ben je ne pige pas trop, ton script devrait être plus rapide que
> portsdb -U pour construire l'index ?

Tu as vu les commentaires qui sont au début de mon script? Ils recoupent
exactement ce que tu vois, sachant que portsdb -U fait tourner make
index. Sur ma machine, make index va plus vite que le script, comme je
le dis. J'ai passé des jours et des jours à essayer de comprendre
pourquoi, sans succés. J'ai écrit plusieurs variantes du script:

- une utilise de l'IO asynchrone et select() pour choisir le pipe qui a
des données. Je me suis aperçu que le parallélisme produit était
faible.
- l'autre, celle que tu as, utilise des threads pour multiplexer les
créations d'index. Elle a un trés bon parallélisme, mais aussi
évidemment de l'overhead.
- une troisième copie exactement ce que fait "make index" sauf les
appels à perl. C'est à dire que je vais par exemple dans
"accessibility" et je fais essentiellement "make -j 3 describe"
exactement comme le fait FreeBSD, en écrivant le résultat des
invocations de make dans un fichier séparé pour chaque port, puis en
relisant et "parsant" ces fichiers. Je m'étais dit, que, aprés tout,
bien que make -j3 utilise des fork() à la place des threads, c'était
peut être plus efficace. Je me suis dit que peut être make restant dans
le cache c'était plus rapide. Par contre il faut tout le temps aller
écrire dans /tmp ce qui est plus lent. J'ai aussi essayé une version en
sortant les résultats des make dans des pipe.

Or, a ma grande surprise, les 3 programmes très différents tournent
exactement dans le même temps, et plus lentement que "make index" qui est
à priori beaucoup plus merdique à cause des 16000 invocations de perl.
La différence ne peut pas être attribuèe à une lenteur éventuelle de
python, car elle est plus grande que le temps total de fonctionnement de
python! Elle est entièrement due à un mauvais agencement des "make"
simultanés.

J'ai même découvert des choses encore plus surprenantes. J'ai écrit 2
petits scripts qui reproduisent ce que fait make index:
niobe% cat essai1_timing.py
#!/usr/local/bin/python
#essai timing
import time, os
tstart = time.time()
os.system("cd /usr/ports/multimedia && make describe")
print time.time() - tstart
# resultat 21.4909200668

niobe% cat essai2_timing.py
#!/usr/local/bin/python
#essai timing
import time, os
tstart = time.time()
os.system('''cd /usr/ports/multimedia && make -B \
-j 2 INDEX_TMPDIR=/tmp/toto BUILDING_INDEX=1 \
PORTSTOP=1 describe ''')
print time.time() - tstart
# resultat 42.0145590305

Le deuxième reproduit *exactement* ou alors je n'ai rien compris, ce que
fait "make index" en mode parallèle. Comme tu peux voir, le benchmark
est désastreux. A titre de comparaison, mes scripts mettent 24s. sur
ce même "multimedia". Note que le simple "make describe" non parallèle
est de loin ce qui donne les meilleurs résultats!

Bref je suis arrivé à la conclusion que je n'y comprenais rien, ou que
tous ces effets sont dus au scheduler complètement défectueux de
FreeBSD, et je suis passé à autre chose ... De toute façon le but de ce
script est rééllement de parser les ports correspondant aux paquets
installés, ce qui prend de l'ordre de 1mn, on n'est pas à 10s. prés.

En ce moment j'écris un petit serveur http qui montre ce que
montreraient les README.html si on les fabriquait.


>
> # /usr/bin/time -h portsdb -U
> Updating the ports index ... Generating INDEX.tmp - please
> 21m37,03s real 16m4,14s user 3m21,52s sys
>
> # /usr/bin/time -h ./build_index.py
> ......accessibility......
> Total time spent: 26 minutes 27 seconds.
> You will find the generated index in INDEX and the errors
> encountered in ErrorLog.
> 26m28,23s real 18m0,15s user 6m48,05s sys
>

--

Michel TALON

Michel Talon :

>> Ben je ne pige pas trop, ton script devrait être plus rapide que
>> portsdb -U pour construire l'index ?
>
> Tu as vu les commentaires qui sont au début de mon script?

Ah oui, méa culpa. C'est étonnant.
[...]

> os.system('''cd /usr/ports/multimedia && make -B \
> -j 2 INDEX_TMPDIR=/tmp/toto BUILDING_INDEX=1 \
> PORTSTOP=1 describe ''')

> Le deuxième reproduit *exactement* ou alors je n'ai rien compris, ce
> que fait "make index" en mode parallèle. Comme tu peux voir, le
> benchmark est désastreux. A titre de comparaison, mes scripts mettent
> 24s. sur ce même "multimedia". Note que le simple "make describe" non
> parallèle est de loin ce qui donne les meilleurs résultats!

Sauf erreur, make index n'utilise pas PORTSTOP=1. Et sans le définir ça
va beaucoup plus vite ( 24s chez moi ). A vue de nez ça se passe dans
ports/Mk/bsd.port.subdir.mk mais je ne pige pas bien le makefile.

> Bref je suis arrivé à la conclusion que je n'y comprenais rien, ou que
> tous ces effets sont dus au scheduler complètement défectueux de
> FreeBSD, et je suis passé à autre chose ... De toute façon le but de
> ce script est rééllement de parser les ports correspondant aux paquets
> installés, ce qui prend de l'ordre de 1mn, on n'est pas à 10s. prés.

D'accord mais si tu veux utiliser portupgrade avec -PP (package only) ou
portinstall il faut bien un index complet, non ?

> En ce moment j'écris un petit serveur http qui montre ce que
> montreraient les README.html si on les fabriquait.

Un moment je les générais mais ça prends des heures et des heures.

--
http://www.lamaiziere.net/logiciels.html

Patrick Lamaizière <adresse@est.invalid> wrote:
>
> Sauf erreur, make index n'utilise pas PORTSTOP=1. Et sans le définir ça
> va beaucoup plus vite ( 24s chez moi ). A vue de nez ça se passe dans
> ports/Mk/bsd.port.subdir.mk mais je ne pige pas bien le makefile.

Moi j'ai l'impression qu'il utilise PORTSTOP=1 parceque c'est uniquement
dans ce cas qu'il se met à écrire des fichiers dans TMPDIR, or le
commentaire dit très clairement que c'est indispensable pour éviter que
les sorties de make describe en parallèle se mélangent.
Et d'ailleurs, si tu regardes /usr/ports/Makefile tu découvres:

SUBDIR += x11-toolkits
SUBDIR += x11-wm

PORTSTOP= yes

..include <bsd.port.subdir.mk>

index:
......

>
> D'accord mais si tu veux utiliser portupgrade avec -PP (package only) ou
> portinstall il faut bien un index complet, non ?
>

Je ne veux pas utiliser portupgrade ni portinstall, je veux faire un
truc à moi, différent. Aussi bien l'un que l'autre me paraissent tout à
fait défectueux. La première étape est de constituer un index des ports
installés et la deuxième d'aller voir sur un serveur ftp quels sont les
paquets précompilés existants. Ensuite il y a moyen de choisir ce qu'on
peut faire venir et ce qu'on doit compiler, puis faire un pkg_delete
général et installer, d'abord les paquets précompilés, puis compiler les
ports restants. A mon avis ça doit être 10 fois plus rapide et fiable
que ce que fait portupgrade.


> > En ce moment j'écris un petit serveur http qui montre ce que
> > montreraient les README.html si on les fabriquait.
>
> Un moment je les générais mais ça prends des heures et des heures.
>

Absolument, c'est bien pourquoi je veux remplacer ça par un serveur qui
calcule les pages à la demande, sachant qu'on va en regarder un petit
nombre de toute façon.


--

Michel TALON

Patrick Lamaizière <adresse@est.invalid> wrote:
> > Bref je suis arrivé à la conclusion que je n'y comprenais rien, ou que
> > tous ces effets sont dus au scheduler complètement défectueux de

Pour préciser, je pense à la chose suivante: le fonctionnement de make
-j 3 consiste à faire des fork() pour des tâches subordonnées (il
construit un arbre de dépendances avant) et de s'arranger pour qu'il y
en ait 3 en permanence. Chacun est un processus et partage
démocratiquement un quantum de temps. Comme ce sont souvent des
processus très courts, au plus 1/10 s. ils ont une priorité élevée. Au
contraire avec un programme long multithreadé comme le script, tous les
threads se partagent le quantum d'un seul processus! C'est ce que les
auteurs de KSE appellent "fair scheduling". En outre comme le processus
est long il prend une priorité faible. Donc les threads ont *très peu*
de temps processeur. Mais alors il se passe la chose suivante: quand
je lance dans un thread:
pipe = popen("make -V <variable>")
certes ceci lance la commande "make -V" dans un processus séparé qui a
une bonne priorité. Mais la sortie de la commande est capturée par un
pipe qui doit être lu par le thread python, qui tourne peu souvent. Il
est bien possible que quelques SIGPIPE soient échangés dans cette
affaire. L'autre possibilité est de faire comme ce que fait make index,
écrire dans un fichier. Par exemple:
system("make -V <variable> > /tmp/toto")
Cette fois ci on n'a plus le problème précédent, mais on en a un autre,
une pression sur le système d'IO, et le résultat, c'est que le temps
système augmente encore et on ne gagne rien. J'ai aussi essayé de lancer
directement la commande que lance make index (genre make -j 3
PORTSTOP=yes, etc.) en me disant que ce coup ci ça ne pouvait que
regagner le temps perdu ... sans aucun résultat. J'ai comme l'impression
que lancer un perl à la suite de chaque make -V, au lieu d'avoir un
effet désastreux donne au contraire au système d'IO le temps de se
refaire une santé. Bref j'ai l'impression que make index est plus rapide
uniquement à cause de déficiences dans l'OS, donc je ne m'intéresse plus
au problème.

> > FreeBSD, et je suis passé à autre chose ... De toute façon le but de
> > ce script est rééllement de parser les ports correspondant aux paquets
> > installés, ce qui prend de l'ordre de 1mn, on n'est pas à 10s. prés.

--

Michel TALON

Michel Talon :

> Moi j'ai l'impression qu'il utilise PORTSTOP=1 parceque c'est
> uniquement dans ce cas qu'il se met à écrire des fichiers dans TMPDIR,
> or le commentaire dit très clairement que c'est indispensable pour
> éviter que les sorties de make describe en parallèle se mélangent.
> Et d'ailleurs, si tu regardes /usr/ports/Makefile tu découvres:

Yep j'ai vu qu'après l'usage de PORTSTOP.

>> D'accord mais si tu veux utiliser portupgrade avec -PP (package only)
>> ou portinstall il faut bien un index complet, non ?
>>
>
> Je ne veux pas utiliser portupgrade ni portinstall, je veux faire un
> truc à moi, différent. Aussi bien l'un que l'autre me paraissent tout
> à fait défectueux.

Je sais ce que tu en penses, personnellement je trouve que ça fonctionne
pas si mal.

> La première étape est de constituer un index des
> ports installés et la deuxième d'aller voir sur un serveur ftp quels
> sont les paquets précompilés existants. Ensuite il y a moyen de
> choisir ce qu'on peut faire venir et ce qu'on doit compiler, puis
> faire un pkg_delete général et installer, d'abord les paquets
> précompilés, puis compiler les ports restants.
> A mon avis ça doit être
> 10 fois plus rapide et fiable que ce que fait portupgrade.

Tu as le risque d'avoir des ports cassés, c'est désagréable alors. Et
même si portupgrade est lent, j'arrive par exemple à mettre à jour tout
KDE en continuant à l'utiliser sans trop de soucis.

Sous NetBSD, "make update" commence par tout désinstaller, je ne trouve
pas que c'est une bonne idée.

Là je regarde l'outil portmaster, qui a l'avantage de faire des "make
config" recursifs et est plus rapide que portupgrade.

--
http://www.lamaiziere.net/logiciels.html

Patrick Lamaizière <adresse@est.invalid> wrote:
>
> Tu as le risque d'avoir des ports cassés, c'est désagréable alors. Et
> même si portupgrade est lent, j'arrive par exemple à mettre à jour tout
> KDE en continuant à l'utiliser sans trop de soucis.
>
> Sous NetBSD, "make update" commence par tout désinstaller, je ne trouve
> pas que c'est une bonne idée.
>

C'est certainement une très mauvaise idéee si on compile soi même à
partir des sources, car on risque effectivement d'avoir des ports
cassés. Par contre si on installe un maximum de paquets précompilés,
par exemple à l'occasion d'une release, alors c'est au contraire une
garantie d'avoir beaucoup *moins* de ports cassés, et d'aller beaucoup
plus vite.

> Là je regarde l'outil portmaster, qui a l'avantage de faire des "make
> config" recursifs et est plus rapide que portupgrade.
>

Ce qui est tout dire sur le caractère défectueux de portupgrade quand on
voit un simple shell script aller plus vite. En ce qui me concerne
l'exemple d'un système efficace est le apt-get de Debian, ce qui veut
dire, utiliser exclusivement (ou quasi exclusivement) des paquets
précompilés, et pratiquer une désinstallation en masse et une
réinstallation en masse. L'idée d'upgrader progressivement, port par
port, comme le fait portupgrade est à mon avis une idée complètement
absurde et, qui outre une lenteur calamiteuse, ne peut avoir que des
résultats désastreux et incohérents. Pour arriver à la faire marcher
coute que coute, les gens se trouvent obligés de vivre en état d'upgrade
permanent.



--

Michel TALON

Le 3 décembre 2006 à 16:04, Patrick Lamaizière a écrit :

> Sous NetBSD, "make update" commence par tout désinstaller, je ne trouve
> pas que c'est une bonne idée.

Surtout quand il foire au milieu. BTDTGTT.

Fred
--
Le fond du continent L'or du nouveau monde
Pyramides jetables Hommes d'affaires impeccables
Quand la pluie de sagesse Pourrit sur les trottoirs
Notre mère la Terre Etonne moi (Noir Désir, Tostaky)

Michel Talon :

>> Là je regarde l'outil portmaster, qui a l'avantage de faire des "make
>> config" recursifs et est plus rapide que portupgrade.
> Ce qui est tout dire sur le caractère défectueux de portupgrade quand
> on voit un simple shell script aller plus vite.

Pas sur le principe de mise à jour, portmaster fait la même chose.

> En ce qui me concerne
> l'exemple d'un système efficace est le apt-get de Debian, ce qui veut
> dire, utiliser exclusivement (ou quasi exclusivement) des paquets
> précompilés, et pratiquer une désinstallation en masse et une
> réinstallation en masse.

D'accord mais il n'y a pas de paquets précompilés à jour disponibles, à
part ceux construits pour -STABLE. Il faudrait des paquets pour
la -RELEASE en cours au moins pour les mises à jours de sécurité.

D'autre part j'ai trop touché aux ports pour que ce soit compatible avec
des paquets compilés avec les options par défauts. À chaque fois que
j'ai voulu importer des paquets j'ai été embêté.

> L'idée d'upgrader progressivement, port par
> port, comme le fait portupgrade est à mon avis une idée complètement
> absurde et, qui outre une lenteur calamiteuse, ne peut avoir que des
> résultats désastreux et incohérents.

Je n'ai jamais eu de problèmes insurmontables, même lors de mises à
jours pénibles du genre perl ou libtool.

> Pour arriver à la faire marcher coute que coute, les gens se trouvent
> obligés de vivre en état d'upgrade permanent.

C'est pas faux bien que « permanent » me semble exagéré. Le problème
c'est que l'arbre des ports évolue très vite et qu'il n'y en a qu'une
version. Je vois mal le projet gérer plusieurs versions ceci dit.

--
http://www.lamaiziere.net/logiciels.html

Patrick Lamaizière <adresse@est.invalid> writes:

'Lut,

> C'est pas faux bien que « permanent » me semble exagéré. Le problème
> c'est que l'arbre des ports évolue très vite et qu'il n'y en a qu'une
> version. Je vois mal le projet gérer plusieurs versions ceci dit.

Ben, pkgsrc s'en sort bien avec les releases trimestrielles.

--
S'il te plait explique moi 2 secondes en quoi c'est un quote de goret,
parce que j'ai cité le message en entier?
c'est normal, je l'ai lu en entier et j'y ai répondu en entier.
-+- B in <http://www.le-gnu.net/> - tout est bon dans le cochon -+-

Patrick Lamaizière <adresse@est.invalid> wrote:
>
> > Pour arriver à la faire marcher coute que coute, les gens se trouvent
> > obligés de vivre en état d'upgrade permanent.
>
> C'est pas faux bien que « permanent » me semble exagéré. Le problème
> c'est que l'arbre des ports évolue très vite et qu'il n'y en a qu'une
> version. Je vois mal le projet gérer plusieurs versions ceci dit.

Oui mais il y a un gel en préparation des "releases" et à ce moment là
il y a une tentative de fixer les bugs et vérifier que ça marche.
Personnellement j'utilise exclusivement les versions de release ainsi
préparées et je me contrefous des mises à jour de sécurité. Evidemment
un administrateur qui a des serveurs exposés sur le web ne peut pas
agir comme ça. Mais aussi il n'a pas 600 ports à upgrader pour se tenir
à jour. Pour tenir des serveurs équipés de quelques ports (disons une
centaine) à jour, je suis d'accord avec toi que portupgrade est une
solution raisonnable.


>

--

Michel TALON

On Sun, 3 Dec 2006 16:28:29 +0000 (UTC)
talon@lpthe.jussieu.fr (Michel Talon) wrote:

> Ce qui est tout dire sur le caractère défectueux de portupgrade quand
> on voit un simple shell script aller plus vite. En ce qui me concerne
> l'exemple d'un système efficace est le apt-get de Debian, ce qui veut
> dire, utiliser exclusivement (ou quasi exclusivement) des paquets
> précompilés, et pratiquer une désinstallation en masse et une
> réinstallation en masse. L'idée d'upgrader progressivement, port par
> port, comme le fait portupgrade est à mon avis une idée complètement
> absurde et, qui outre une lenteur calamiteuse, ne peut avoir que des
> résultats désastreux et incohérents. Pour arriver à la faire marcher
> coute que coute, les gens se trouvent obligés de vivre en état
> d'upgrade permanent.

Hum ... c'est un vaste débat cette histoire de paquets pré-compilés.
C'est justement la raison qui fait que je n'aime pas les distribs
linux. J'ai des options spécifiques sur pas mal de ports, des
configurations personnelles ici ou là, un système tout binaire ne me
convient pas (ou alors, les mainteneurs ont de la place et du temps et
ils produisent un binaire pour toutes les combinaisons d'options
possibles ... )

Globalement la solution de portupgrade est satisfaisante, même si les
usines à gaz comme gnome peuvent parfois poser problème (d'un autre
côté, on ne peut pas obtenir mieux avec un projet composé d'un paquet
de lib qui changent tous les 6 mois.) À mon avis écrit dans un autre
langage que ruby les choses se passeraient mieux, portmaster en est la
preuve (il n'y a rien de pire qu'un langage interprété qui se veux
aussi évoluer qu'un langage compilé, en général on hérite du pire des
deux mondes.)

L'upgrade "port par port" n'est pas forcément mauvaise (moi je la
trouve plutôt bien et pratique) en règle général, mise à part les libs
utilisées par tout le monde, ou les projets usines à gaz comme gnome,
tu peux très bien vivre avec un système partiellement à jour et mettre
à jour les ports un par un, lorsque tu as du temps (la nuit par
exemple, raison pour laquelle je suis en train d'adopter portmaster,
qui pose toutes ses questions avant de faire l'upgrade.)

La seule solution avec binaires "satisfaisante" serait de reconstruire
le port et de l'installer avec un PREFIX différent pour tout construire
dans un environnement "propre" (mais disposant des packages existant et
à jour) avant de tout désinstaller/réinstaller. Plus ou moins ce que tu
préconise, mais avec la recompile en local pour pouvoir choisir les
options. Mais cette solution prend de la place ... (j'entends déjà
Marc dire que c'est plus ou moins ce qui se passe dans open, n'est ce
pas ?

--
<Jayce> moi je n'ai pas beaucoup de savoir, mais bcp d'intelligence, car
je sais me sortir de tous les problèmes rencontrés
-- Jayce - Ph34r ! --

Marwan Burelle <feanor@kh405.net> wrote:
> de lib qui changent tous les 6 mois.) À mon avis écrit dans un autre
> langage que ruby les choses se passeraient mieux, portmaster en est la
> preuve (il n'y a rien de pire qu'un langage interprété qui se veux
> aussi évoluer qu'un langage compilé, en général on hérite du pire des
> deux mondes.)

Portmaster fait énormément moins de choses que portupgrade, il faut
bien dire. Mais tu as raison ruby est de tous les langages de son genre,
le plus lent et de loin. De mon point de vue il réussit surtout à
avoir le caractère cryptique de perl sans en avoir aucun des
avantages de performance, j'ai du mal à comprendre sa popularité.

>
> L'upgrade "port par port" n'est pas forcément mauvaise (moi je la

si ce n'est que tu peux te retrouver très facilement avec des programmes
qui plantent tout le temps parcequ'il aurait fallu upgrader un composant
que le système ne t'a pas fait upgrader. ca m'est arrivé plus d'une fois
avec firefox.

>
> La seule solution avec binaires "satisfaisante" serait de reconstruire
> le port et de l'installer avec un PREFIX différent pour tout construire
> dans un environnement "propre" (mais disposant des packages existant et
> à jour) avant de tout désinstaller/réinstaller. Plus ou moins ce que tu
> préconise, mais avec la recompile en local pour pouvoir choisir les
> options. Mais cette solution prend de la place ... (j'entends déjà
> Marc dire que c'est plus ou moins ce qui se passe dans open, n'est ce
> pas ?

Ce système est certainement le plus sûr et même probablement le seul qui
est à la fois adapté à la fois à l'utilisateur et sûr. Le problème de
place est à mon avis totalement insignifiant à l'heure actuelle. J'ai
entendu dire qu'il y a des gens qui font ça dans une jail pour éviter
toute pollution de l'environnement de départ, il faut dire que le
système n'est vraîment pas fait pour faciliter les choses et en
particulier tu te retrouves avec des pollutions automatiques d'une façon
complètement invraisemblable, comme par exemple tu te retrouves avec un
gimp-gnome si tu as gnome installé et gimp sinon, sans que tu ais
demandé quoi que ce soit dans tes options. Qui a pu avoir l'idée
d'âneries pareilles, je me demande bien - le mec est rééllement bon pour
Sainte Anne. C'est aussi pour ça et pour ne pas me casser les méninges
que j'aime bien installer les ports précompilés avec les options
standard, comme ça on peut espérer que ça marche - sinon quelqu'un
aurait râlé pendant le port freeze. Dés qu'une option non standard est
en jeu on peut s'attendre à tout. Qu'on le fasse pour un programme
auquel on tient particulièrement, passe, mais pour KDE, les options de
compilation m'indiffèrent totalement, tant que ça marche.


>

--

Michel TALON

Dimanche 03 décembre 2006 à 22:00 GMT, Marwan Burelle a écrit:

> La seule solution avec binaires "satisfaisante" serait de reconstruire
> le port et de l'installer avec un PREFIX différent pour tout construire
> dans un environnement "propre" (mais disposant des packages existant et
> à jour) avant de tout désinstaller/réinstaller. Plus ou moins ce que tu
> préconise, mais avec la recompile en local pour pouvoir choisir les
> options. Mais cette solution prend de la place ... (j'entends déjà
> Marc dire que c'est plus ou moins ce qui se passe dans open, n'est ce
> pas ?

C'est ce que je fais sur une machine assez puissante avec une Tinderbox
(du port misc/tinderbox). C'est vrai que ça demande de la place, mais au
vu des disques actuels, ça n'est plus un problème.
--
Th. Thomas.

In article <ekvirs$74r$1@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> wrote:
>Marwan Burelle <feanor@kh405.net> wrote:
>> La seule solution avec binaires "satisfaisante" serait de reconstruire
>> le port et de l'installer avec un PREFIX différent pour tout construire
>> dans un environnement "propre" (mais disposant des packages existant et
>> à jour) avant de tout désinstaller/réinstaller. Plus ou moins ce que tu
>> préconise, mais avec la recompile en local pour pouvoir choisir les
>> options. Mais cette solution prend de la place ... (j'entends déjà
>> Marc dire que c'est plus ou moins ce qui se passe dans open, n'est ce
>> pas ?

Pas tout a fait ce qu'on fait, mais pas tres loin. On sait mettre a jour
des paquets `en place', meme s'ils sont necessaires pour d'autres choses,
parce qu'on met a jour systematiquement les numeros de version de bibliotheque
histoire qu'elles puissent cohabiter.

>Ce système est certainement le plus sûr et même probablement le seul qui
>est à la fois adapté à la fois à l'utilisateur et sûr. Le problème de
>place est à mon avis totalement insignifiant à l'heure actuelle. J'ai
>entendu dire qu'il y a des gens qui font ça dans une jail pour éviter
>toute pollution de l'environnement de départ, il faut dire que le
>système n'est vraîment pas fait pour faciliter les choses et en
>particulier tu te retrouves avec des pollutions automatiques d'une façon
>complètement invraisemblable, comme par exemple tu te retrouves avec un
>gimp-gnome si tu as gnome installé et gimp sinon, sans que tu ais
>demandé quoi que ce soit dans tes options. Qui a pu avoir l'idée
>d'âneries pareilles, je me demande bien - le mec est rééllement bon pour
>Sainte Anne.

Tout ca, on le doit quand meme aux aneries des gars de chez gnu.

Controle de la construction precise des bibliotheques, numero de version
compris -> il faut patcher libtool.

Detection automatique de trucs installes -> j'ai deja dit tout le mal
que je pensais d'autoconf ?

Possibilite de construire des trucs proprement sans devoir passer par
un chroot -> rendu tres difficile par la conjonction d'autoconf, libtool,
et pkg-config. Aucun des trois n'a de notion vraiment satisfaisante de
logiciels en cours de construction.

Ah, sans compter le fait que tout ceci se veut tres hypocritement portable,
et teste donc plein de trucs qu'on n'a pas vu depuis des decennies.

Par contre, si tu ne te conformes pas au modele habituel de bibliotheques
partagees ELF, bon courage... ca fout la merde a peu pres partout...

Tout ca pour dire que, petit a petit, on se retrouve a re-ecrire de gros
bouts (voire la totalite) de libtool, pkg-config, et assimiles. Pas pour
faire chier, juste parce que ces trucs sont sous licence GPL, mais surtout
parce qu'ils nous brisent les burnes en permanence, sont trop compliques
pour ce qu'ils font, sont pratiquement toujours ecrits dans un langage
inadapte, et bloquent une quantite de trucs invraisemblables.

Par exemple, j'avais un proto de recompile complete sans installation il y
a deux ans. J'avais meme commence a convertir quelques vrais ports pour voir
(des trucs comme xv, par exemple). Ca a brutalement foire des que je suis
tombe sur des sorties de libtool et de pkg-config, et que j'ai constate
que je n'avais aucun moyen simple de reprendre leur resultat et de dire
`oui, bon, le logiciel devait etre installe dans /usr/local, mais en fait
il est dans /usr/ports/w-truc/deps/usr/local, donc ajuste les chemins en
consequence'. Malgre toute la `generalite' des outils gnu, pkg-config avait
des /usr/local hardcodes une fois sur deux (ou le truc foutu de telle sorte
que je me retrouvais avec un -L/usr/ports/w-truc/deps/usr/local ET un
-rpath /usr/ports/w-truc/deps/usr/local). Quant aux .la, je prefererais
ne pas en parler. Ca ressemble a des shell-scripts, mais c'est foutu
de telle sorte qu'on ne peut meme pas les modifier apres coup...

La on est deux ans plus tard, et je m'oriente definitivement vers des outils
qui savent lire et modifier des .pc et .la de maniere profonde, et je sais
pertinement qu'il faut que je finisse le reverse-engineering des bugs de
libtool pour en tirer une version qui marche (et qui sera sans doute dix
fois plus vite que l'original).

Mais, encore une fois, j'ai l'impression d'avoir passe l'essentiel de mon
temps a me battre contre les autotools, au lieu de porter des nouveaux
trucs...