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