Utilisateur de Linux depuis plusieurs années je découvre petit à petit
le monde FreeBSD. Je voudrais tout d'abord saluer le travail fait autour
du handbook qui est assez exceptionnel.
Cela dit, je suis un peu perdu dans gestion des paquets sous ce système.
Je constate qu'il existe plusieurs dépots binaires sur le serveur FTP:
D'après ce j'ai compris, reprenez moi si je me trompe, le suffixe
"-stable" indique que les paquets on été construit avec un version
"-stable" du système. Même chose pour "-release" et "-current".
Ce que j'ignore pour le moment c'est la fréquence à laquelle ces
paquetages sont mis à jour. (Je suppose que "-release" ne bouge jamais,
même pas pour des correctifs touchant à la sécurité du système).
Voici ce que j'envisage de faire pour la première installation du
système. Installer FreeBSD à partir du CD sans installer aucun package.
Installation des "gros" paquets genre Xorg, firefox, etc via le dépot
"packages-6-stable" du FTP. Mis à jour régulière via les ports avec
portmanager. Ma démarche est-elle correcte ?
Je ne sais pas pour portmanager, on utilise portupgrade en général voir portmaster.
Beurk !!! Ca me fait penser a Debian et ses apt-get machintruc, avec une
surcouche DPKG (ou l'inerse je sais plus) et encore une troisième couche pour gérer les deux couches du dessus ....
C'est peut être ce qui explique que parfois ce groupe est si calme, tout le monde change les couches (voir http://groups.google.fr/group/fr.comp.os.bsd/browse_thread/thread/f6255a92e6ea6e60/e3af6c9803e38529?hl=fr&lnk=gst&q=enfant+couches#e3af6c9803e38529 )
Je me demande parfois pourquoi j'ai préféré NetBSD a FreeBSD, et quand je lis ça je me le rappelle ...
Alors la, c'est l'hopital qui se fout de la charite.
Moi je ne me demande pas pourquoi j'ai reecrit le pkg_add(1) d'OpenBSD en perl, c'est precisement pour eviter tous ces problemes.
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes ces surcouches qui passent leur temps a essayer de reconstituer des informations semantiques que les couches d'en dessous ont perdu.
Perl m'a permis d'avoir un formalisme raisonnable: le pkg_add d'OpenBSD gere reellement les dependances et les mises-a-jour, parce qu'il sait calculer sur toutes les infos que contiennent maintenant nos packages pour effectuer directement ce type d'operation. D'une part, il ne se plante pas, et d'autre part, il va vite, voire meme tres vite pour un outil ecrit en perl.
A l'arrivee, on a un systeme complet qui fonctionne. Le truc qui perd le plus les noob sous open, c'est qu'il faut leur dire trois fois que notre pkg_add fonctionne, et qu'il n'y a pas besoin de 3 millions d'outils au-dessus pour en faire quelque chose (si, si, les mise-a-jour fonctionnent, je t'assure).
Ah, et on n'a pas non plus ruby dans le systeme de base. Mais perl, si ;)
Bon, c'etait mon rant du jour. Et puis zut, apres le nombre d'heures que j'ai passe sur le design de ce truc, et pour le faire marcher, j'estime que je peux la ramener ;-)
In article <47588376$0$2492$426a74cc@news.free.fr>,
totof2000 <nospam@nospam.org> wrote:
Je ne sais pas pour portmanager, on utilise portupgrade en général voir
portmaster.
Beurk !!! Ca me fait penser a Debian et ses apt-get machintruc, avec une
surcouche DPKG (ou l'inerse je sais plus) et encore une troisième couche
pour gérer les deux couches du dessus ....
C'est peut être ce qui explique que parfois ce groupe est si calme, tout
le monde change les couches (voir
http://groups.google.fr/group/fr.comp.os.bsd/browse_thread/thread/f6255a92e6ea6e60/e3af6c9803e38529?hl=fr&lnk=gst&q=enfant+couches#e3af6c9803e38529
)
Je me demande parfois pourquoi j'ai préféré NetBSD a FreeBSD, et quand
je lis ça je me le rappelle ...
Alors la, c'est l'hopital qui se fout de la charite.
Moi je ne me demande pas pourquoi j'ai reecrit le pkg_add(1) d'OpenBSD en
perl, c'est precisement pour eviter tous ces problemes.
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson
rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes
ces surcouches qui passent leur temps a essayer de reconstituer des
informations semantiques que les couches d'en dessous ont perdu.
Perl m'a permis d'avoir un formalisme raisonnable: le pkg_add d'OpenBSD
gere reellement les dependances et les mises-a-jour, parce qu'il sait
calculer sur toutes les infos que contiennent maintenant nos packages
pour effectuer directement ce type d'operation. D'une part, il ne se
plante pas, et d'autre part, il va vite, voire meme tres vite pour un
outil ecrit en perl.
A l'arrivee, on a un systeme complet qui fonctionne. Le truc qui perd
le plus les noob sous open, c'est qu'il faut leur dire trois fois que
notre pkg_add fonctionne, et qu'il n'y a pas besoin de 3 millions
d'outils au-dessus pour en faire quelque chose (si, si, les mise-a-jour
fonctionnent, je t'assure).
Ah, et on n'a pas non plus ruby dans le systeme de base. Mais perl, si ;)
Bon, c'etait mon rant du jour. Et puis zut, apres le nombre d'heures
que j'ai passe sur le design de ce truc, et pour le faire marcher,
j'estime que je peux la ramener ;-)
Je ne sais pas pour portmanager, on utilise portupgrade en général voir portmaster.
Beurk !!! Ca me fait penser a Debian et ses apt-get machintruc, avec une
surcouche DPKG (ou l'inerse je sais plus) et encore une troisième couche pour gérer les deux couches du dessus ....
C'est peut être ce qui explique que parfois ce groupe est si calme, tout le monde change les couches (voir http://groups.google.fr/group/fr.comp.os.bsd/browse_thread/thread/f6255a92e6ea6e60/e3af6c9803e38529?hl=fr&lnk=gst&q=enfant+couches#e3af6c9803e38529 )
Je me demande parfois pourquoi j'ai préféré NetBSD a FreeBSD, et quand je lis ça je me le rappelle ...
Alors la, c'est l'hopital qui se fout de la charite.
Moi je ne me demande pas pourquoi j'ai reecrit le pkg_add(1) d'OpenBSD en perl, c'est precisement pour eviter tous ces problemes.
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes ces surcouches qui passent leur temps a essayer de reconstituer des informations semantiques que les couches d'en dessous ont perdu.
Perl m'a permis d'avoir un formalisme raisonnable: le pkg_add d'OpenBSD gere reellement les dependances et les mises-a-jour, parce qu'il sait calculer sur toutes les infos que contiennent maintenant nos packages pour effectuer directement ce type d'operation. D'une part, il ne se plante pas, et d'autre part, il va vite, voire meme tres vite pour un outil ecrit en perl.
A l'arrivee, on a un systeme complet qui fonctionne. Le truc qui perd le plus les noob sous open, c'est qu'il faut leur dire trois fois que notre pkg_add fonctionne, et qu'il n'y a pas besoin de 3 millions d'outils au-dessus pour en faire quelque chose (si, si, les mise-a-jour fonctionnent, je t'assure).
Ah, et on n'a pas non plus ruby dans le systeme de base. Mais perl, si ;)
Bon, c'etait mon rant du jour. Et puis zut, apres le nombre d'heures que j'ai passe sur le design de ce truc, et pour le faire marcher, j'estime que je peux la ramener ;-)
talon
totof2000 wrote:
Comment c'est fait dans NetBSD ? Il y a un seul outil qui gère le dépaquetage, l'installation, le download, les dépendances, etc ?
Oui.
C'est à dire qu'il n'y a aucune gestion sérieuse de dépendance, selon le bruit qui court ...
--
Michel TALON
totof2000 <nospam@nospam.org> wrote:
Comment c'est fait dans NetBSD ?
Il y a un seul outil qui gère le dépaquetage, l'installation, le
download, les dépendances, etc ?
Oui.
C'est à dire qu'il n'y a aucune gestion sérieuse de dépendance, selon
le bruit qui court ...
Comment c'est fait dans NetBSD ? Il y a un seul outil qui gère le dépaquetage, l'installation, le download, les dépendances, etc ?
Oui.
C'est à dire qu'il n'y a aucune gestion sérieuse de dépendance, selon le bruit qui court ...
--
Michel TALON
totof2000
C'est à dire qu'il n'y a aucune gestion sérieuse de dépendance, selon le bruit qui court ...
J'utilise NetBSD depuis quelques années maintenant et je n'ai jamais rencontré de problème majeur sur l'installation des packages et de leurs dépendances ....
Si je veux installer un package, je fais un pkg_add nom_du_package et ça passe. Si je veux compiler: make package et ça passe aussi. Les seuls problèmes que j'ai rencontrés pour la compilation sont xorg et OpenOffice, mais rien de bien méchant. Sous Debian j'ai eu plus de problèmes (mais je reconnais que je maitrise moins ce système).
C'est à dire qu'il n'y a aucune gestion sérieuse de dépendance, selon
le bruit qui court ...
J'utilise NetBSD depuis quelques années maintenant et je n'ai jamais
rencontré de problème majeur sur l'installation des packages et de leurs
dépendances ....
Si je veux installer un package, je fais un pkg_add nom_du_package et ça
passe. Si je veux compiler: make package et ça passe aussi. Les seuls
problèmes que j'ai rencontrés pour la compilation sont xorg et
OpenOffice, mais rien de bien méchant. Sous Debian j'ai eu plus de
problèmes (mais je reconnais que je maitrise moins ce système).
C'est à dire qu'il n'y a aucune gestion sérieuse de dépendance, selon le bruit qui court ...
J'utilise NetBSD depuis quelques années maintenant et je n'ai jamais rencontré de problème majeur sur l'installation des packages et de leurs dépendances ....
Si je veux installer un package, je fais un pkg_add nom_du_package et ça passe. Si je veux compiler: make package et ça passe aussi. Les seuls problèmes que j'ai rencontrés pour la compilation sont xorg et OpenOffice, mais rien de bien méchant. Sous Debian j'ai eu plus de problèmes (mais je reconnais que je maitrise moins ce système).
totof2000
Moi je ne me demande pas pourquoi j'ai reecrit le pkg_add(1) d'OpenBSD en perl, c'est precisement pour eviter tous ces problemes.
Quels problèmes?
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes ces surcouches qui passent leur temps a essayer de reconstituer des informations semantiques que les couches d'en dessous ont perdu.
Comprend pas, j'ai jamais eu de problème sous NetBSD, et je ne connais pas suffisamment OpenBSD pour juger de son système de package. Ce qui est sur c'est que je n'aime pas trop l'aproche FreeBSD parce qu'elle me fait trop penser à une Debian. Et j'ai jamais accroché sur Debian.
Perl m'a permis d'avoir un formalisme raisonnable: le pkg_add d'OpenBSD gere reellement les dependances et les mises-a-jour, parce qu'il sait calculer sur toutes les infos que contiennent maintenant nos packages pour effectuer directement ce type d'operation. D'une part, il ne se plante pas, et d'autre part, il va vite, voire meme tres vite pour un outil ecrit en perl.
Mais pourquoi donc as-tu eu à réécrire pkg_add pour Open? Si j'ai bien suivi l'affaire, à l'origine, pkg_add sur OpenBSD était le même que sur NetBSD non ? Alors, quelles sont les lacunes qui t'ont poussé à faire ce travail de titan?
A l'arrivee, on a un systeme complet qui fonctionne. Le truc qui perd le plus les noob sous open, c'est qu'il faut leur dire trois fois que notre pkg_add fonctionne, et qu'il n'y a pas besoin de 3 millions d'outils au-dessus pour en faire quelque chose (si, si, les mise-a-jour fonctionnent, je t'assure).
Bah, je répète, sous NetBSD chezmoicamarche, ou quand ça marche pas, y a rien de méchant à régler (faut dire aussi que je suis pas un fan des trucs style KDE/Gnome ou tout ces méga-machins qui ont des dépendances dans tous les sens).
Ah, et on n'a pas non plus ruby dans le systeme de base. Mais perl, si ;)
Comme dans beaucoup d'autres Unix ...
Bon, c'etait mon rant du jour. Et puis zut, apres le nombre d'heures que j'ai passe sur le design de ce truc, et pour le faire marcher, j'estime que je peux la ramener ;-)
Je crois que tu t'es trompé de cible. Je parlais des surcouches à la debian/freeBSD, pas d'OpenBSD: je ne l'utilise pas (mais tu as éveillé ma curiosité).
Juste une question: est-ce que OpenBSD tourne en DomU/dom0 sous Xen ?
Moi je ne me demande pas pourquoi j'ai reecrit le pkg_add(1) d'OpenBSD en
perl, c'est precisement pour eviter tous ces problemes.
Quels problèmes?
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson
rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes
ces surcouches qui passent leur temps a essayer de reconstituer des
informations semantiques que les couches d'en dessous ont perdu.
Comprend pas, j'ai jamais eu de problème sous NetBSD, et je ne connais
pas suffisamment OpenBSD pour juger de son système de package. Ce qui
est sur c'est que je n'aime pas trop l'aproche FreeBSD parce qu'elle me
fait trop penser à une Debian. Et j'ai jamais accroché sur Debian.
Perl m'a permis d'avoir un formalisme raisonnable: le pkg_add d'OpenBSD
gere reellement les dependances et les mises-a-jour, parce qu'il sait
calculer sur toutes les infos que contiennent maintenant nos packages
pour effectuer directement ce type d'operation. D'une part, il ne se
plante pas, et d'autre part, il va vite, voire meme tres vite pour un
outil ecrit en perl.
Mais pourquoi donc as-tu eu à réécrire pkg_add pour Open? Si j'ai bien
suivi l'affaire, à l'origine, pkg_add sur OpenBSD était le même que sur
NetBSD non ? Alors, quelles sont les lacunes qui t'ont poussé à faire ce
travail de titan?
A l'arrivee, on a un systeme complet qui fonctionne. Le truc qui perd
le plus les noob sous open, c'est qu'il faut leur dire trois fois que
notre pkg_add fonctionne, et qu'il n'y a pas besoin de 3 millions
d'outils au-dessus pour en faire quelque chose (si, si, les mise-a-jour
fonctionnent, je t'assure).
Bah, je répète, sous NetBSD chezmoicamarche, ou quand ça marche pas, y a
rien de méchant à régler (faut dire aussi que je suis pas un fan des
trucs style KDE/Gnome ou tout ces méga-machins qui ont des dépendances
dans tous les sens).
Ah, et on n'a pas non plus ruby dans le systeme de base. Mais perl, si ;)
Comme dans beaucoup d'autres Unix ...
Bon, c'etait mon rant du jour. Et puis zut, apres le nombre d'heures
que j'ai passe sur le design de ce truc, et pour le faire marcher,
j'estime que je peux la ramener ;-)
Je crois que tu t'es trompé de cible. Je parlais des surcouches à la
debian/freeBSD, pas d'OpenBSD: je ne l'utilise pas (mais tu as éveillé
ma curiosité).
Juste une question: est-ce que OpenBSD tourne en DomU/dom0 sous Xen ?
Moi je ne me demande pas pourquoi j'ai reecrit le pkg_add(1) d'OpenBSD en perl, c'est precisement pour eviter tous ces problemes.
Quels problèmes?
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes ces surcouches qui passent leur temps a essayer de reconstituer des informations semantiques que les couches d'en dessous ont perdu.
Comprend pas, j'ai jamais eu de problème sous NetBSD, et je ne connais pas suffisamment OpenBSD pour juger de son système de package. Ce qui est sur c'est que je n'aime pas trop l'aproche FreeBSD parce qu'elle me fait trop penser à une Debian. Et j'ai jamais accroché sur Debian.
Perl m'a permis d'avoir un formalisme raisonnable: le pkg_add d'OpenBSD gere reellement les dependances et les mises-a-jour, parce qu'il sait calculer sur toutes les infos que contiennent maintenant nos packages pour effectuer directement ce type d'operation. D'une part, il ne se plante pas, et d'autre part, il va vite, voire meme tres vite pour un outil ecrit en perl.
Mais pourquoi donc as-tu eu à réécrire pkg_add pour Open? Si j'ai bien suivi l'affaire, à l'origine, pkg_add sur OpenBSD était le même que sur NetBSD non ? Alors, quelles sont les lacunes qui t'ont poussé à faire ce travail de titan?
A l'arrivee, on a un systeme complet qui fonctionne. Le truc qui perd le plus les noob sous open, c'est qu'il faut leur dire trois fois que notre pkg_add fonctionne, et qu'il n'y a pas besoin de 3 millions d'outils au-dessus pour en faire quelque chose (si, si, les mise-a-jour fonctionnent, je t'assure).
Bah, je répète, sous NetBSD chezmoicamarche, ou quand ça marche pas, y a rien de méchant à régler (faut dire aussi que je suis pas un fan des trucs style KDE/Gnome ou tout ces méga-machins qui ont des dépendances dans tous les sens).
Ah, et on n'a pas non plus ruby dans le systeme de base. Mais perl, si ;)
Comme dans beaucoup d'autres Unix ...
Bon, c'etait mon rant du jour. Et puis zut, apres le nombre d'heures que j'ai passe sur le design de ce truc, et pour le faire marcher, j'estime que je peux la ramener ;-)
Je crois que tu t'es trompé de cible. Je parlais des surcouches à la debian/freeBSD, pas d'OpenBSD: je ne l'utilise pas (mais tu as éveillé ma curiosité).
Juste une question: est-ce que OpenBSD tourne en DomU/dom0 sous Xen ?
espie
In article <4759dd20$0$12570$, totof2000 wrote:
Moi je ne me demande pas pourquoi j'ai reecrit le pkg_add(1) d'OpenBSD en perl, c'est precisement pour eviter tous ces problemes.
Quels problèmes?
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes ces surcouches qui passent leur temps a essayer de reconstituer des informations semantiques que les couches d'en dessous ont perdu.
Comprend pas, j'ai jamais eu de problème sous NetBSD, et je ne connais pas suffisamment OpenBSD pour juger de son système de package. Ce qui est sur c'est que je n'aime pas trop l'aproche FreeBSD parce qu'elle me fait trop penser à une Debian. Et j'ai jamais accroché sur Debian.
Perl m'a permis d'avoir un formalisme raisonnable: le pkg_add d'OpenBSD gere reellement les dependances et les mises-a-jour, parce qu'il sait calculer sur toutes les infos que contiennent maintenant nos packages pour effectuer directement ce type d'operation. D'une part, il ne se plante pas, et d'autre part, il va vite, voire meme tres vite pour un outil ecrit en perl.
Mais pourquoi donc as-tu eu à réécrire pkg_add pour Open? Si j'ai bien suivi l'affaire, à l'origine, pkg_add sur OpenBSD était le même que sur NetBSD non ? Alors, quelles sont les lacunes qui t'ont poussé à faire ce travail de titan?
Parce que ca ne marchait pas, essentiellement. D'abord parce que le pkg_add initial, celui de PHK, etait une horreur cote trous divers sur les chaines de caracteres, ensuite parce que la gestion de dependances etait a moitie bugguee, et super-lente, et aussi parce que ca ne supportait pas les mises-a-jour.
D'ailleurs, ton `ca marche'. bof. Il y a encore pas mal de problemes... je suis suffisamment les ml de netbsd pour les voir... Globalement, pour les mise-a-jour, vous etes encore pas mal en mode `on enleve les vieux trucs et on installe les nouveaux', ce qui est souvent pas mal couteux. Sans compter le fait que les packages sont loin d'etre verifies systematiquement, puisque tous vos packages ne sont pas encore DESTDIR-clean.
Je passe pudiquement sur tout un ensemble de details... Le seul vrai point ou netbsd est en avance, c'est buildlink.
A l'arrivee, on a un systeme complet qui fonctionne. Le truc qui perd le plus les noob sous open, c'est qu'il faut leur dire trois fois que notre pkg_add fonctionne, et qu'il n'y a pas besoin de 3 millions d'outils au-dessus pour en faire quelque chose (si, si, les mise-a-jour fonctionnent, je t'assure).
Bah, je répète, sous NetBSD chezmoicamarche, ou quand ça marche pas, y a rien de méchant à régler (faut dire aussi que je suis pas un fan des trucs style KDE/Gnome ou tout ces méga-machins qui ont des dépendances dans tous les sens).
Oui, en gros tu utilises les cas super-simples ou ca marche presque toujours, quoi ;-)
Un autre GROS avantage, c'est que ca a permis d'unifier un peu tous les scripts divers des ports et packages. On n'a plus qu'une seule routine de gestion de packing-list (ecrite en perl), et ca se voit... ;-)
Juste une question: est-ce que OpenBSD tourne en DomU/dom0 sous Xen ?
pas que je sache.
In article <4759dd20$0$12570$426a34cc@news.free.fr>,
totof2000 <nospam@nospam.org> wrote:
Moi je ne me demande pas pourquoi j'ai reecrit le pkg_add(1) d'OpenBSD en
perl, c'est precisement pour eviter tous ces problemes.
Quels problèmes?
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson
rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes
ces surcouches qui passent leur temps a essayer de reconstituer des
informations semantiques que les couches d'en dessous ont perdu.
Comprend pas, j'ai jamais eu de problème sous NetBSD, et je ne connais
pas suffisamment OpenBSD pour juger de son système de package. Ce qui
est sur c'est que je n'aime pas trop l'aproche FreeBSD parce qu'elle me
fait trop penser à une Debian. Et j'ai jamais accroché sur Debian.
Perl m'a permis d'avoir un formalisme raisonnable: le pkg_add d'OpenBSD
gere reellement les dependances et les mises-a-jour, parce qu'il sait
calculer sur toutes les infos que contiennent maintenant nos packages
pour effectuer directement ce type d'operation. D'une part, il ne se
plante pas, et d'autre part, il va vite, voire meme tres vite pour un
outil ecrit en perl.
Mais pourquoi donc as-tu eu à réécrire pkg_add pour Open? Si j'ai bien
suivi l'affaire, à l'origine, pkg_add sur OpenBSD était le même que sur
NetBSD non ? Alors, quelles sont les lacunes qui t'ont poussé à faire ce
travail de titan?
Parce que ca ne marchait pas, essentiellement. D'abord parce que le
pkg_add initial, celui de PHK, etait une horreur cote trous divers sur
les chaines de caracteres, ensuite parce que la gestion de dependances
etait a moitie bugguee, et super-lente, et aussi parce que ca ne supportait
pas les mises-a-jour.
D'ailleurs, ton `ca marche'. bof. Il y a encore pas mal de problemes...
je suis suffisamment les ml de netbsd pour les voir... Globalement, pour
les mise-a-jour, vous etes encore pas mal en mode `on enleve les vieux
trucs et on installe les nouveaux', ce qui est souvent pas mal couteux.
Sans compter le fait que les packages sont loin d'etre verifies
systematiquement, puisque tous vos packages ne sont pas encore DESTDIR-clean.
Je passe pudiquement sur tout un ensemble de details...
Le seul vrai point ou netbsd est en avance, c'est buildlink.
A l'arrivee, on a un systeme complet qui fonctionne. Le truc qui perd
le plus les noob sous open, c'est qu'il faut leur dire trois fois que
notre pkg_add fonctionne, et qu'il n'y a pas besoin de 3 millions
d'outils au-dessus pour en faire quelque chose (si, si, les mise-a-jour
fonctionnent, je t'assure).
Bah, je répète, sous NetBSD chezmoicamarche, ou quand ça marche pas, y a
rien de méchant à régler (faut dire aussi que je suis pas un fan des
trucs style KDE/Gnome ou tout ces méga-machins qui ont des dépendances
dans tous les sens).
Oui, en gros tu utilises les cas super-simples ou ca marche presque toujours,
quoi ;-)
Un autre GROS avantage, c'est que ca a permis d'unifier un peu tous les
scripts divers des ports et packages. On n'a plus qu'une seule routine
de gestion de packing-list (ecrite en perl), et ca se voit... ;-)
Juste une question: est-ce que OpenBSD tourne en DomU/dom0 sous Xen ?
Moi je ne me demande pas pourquoi j'ai reecrit le pkg_add(1) d'OpenBSD en perl, c'est precisement pour eviter tous ces problemes.
Quels problèmes?
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes ces surcouches qui passent leur temps a essayer de reconstituer des informations semantiques que les couches d'en dessous ont perdu.
Comprend pas, j'ai jamais eu de problème sous NetBSD, et je ne connais pas suffisamment OpenBSD pour juger de son système de package. Ce qui est sur c'est que je n'aime pas trop l'aproche FreeBSD parce qu'elle me fait trop penser à une Debian. Et j'ai jamais accroché sur Debian.
Perl m'a permis d'avoir un formalisme raisonnable: le pkg_add d'OpenBSD gere reellement les dependances et les mises-a-jour, parce qu'il sait calculer sur toutes les infos que contiennent maintenant nos packages pour effectuer directement ce type d'operation. D'une part, il ne se plante pas, et d'autre part, il va vite, voire meme tres vite pour un outil ecrit en perl.
Mais pourquoi donc as-tu eu à réécrire pkg_add pour Open? Si j'ai bien suivi l'affaire, à l'origine, pkg_add sur OpenBSD était le même que sur NetBSD non ? Alors, quelles sont les lacunes qui t'ont poussé à faire ce travail de titan?
Parce que ca ne marchait pas, essentiellement. D'abord parce que le pkg_add initial, celui de PHK, etait une horreur cote trous divers sur les chaines de caracteres, ensuite parce que la gestion de dependances etait a moitie bugguee, et super-lente, et aussi parce que ca ne supportait pas les mises-a-jour.
D'ailleurs, ton `ca marche'. bof. Il y a encore pas mal de problemes... je suis suffisamment les ml de netbsd pour les voir... Globalement, pour les mise-a-jour, vous etes encore pas mal en mode `on enleve les vieux trucs et on installe les nouveaux', ce qui est souvent pas mal couteux. Sans compter le fait que les packages sont loin d'etre verifies systematiquement, puisque tous vos packages ne sont pas encore DESTDIR-clean.
Je passe pudiquement sur tout un ensemble de details... Le seul vrai point ou netbsd est en avance, c'est buildlink.
A l'arrivee, on a un systeme complet qui fonctionne. Le truc qui perd le plus les noob sous open, c'est qu'il faut leur dire trois fois que notre pkg_add fonctionne, et qu'il n'y a pas besoin de 3 millions d'outils au-dessus pour en faire quelque chose (si, si, les mise-a-jour fonctionnent, je t'assure).
Bah, je répète, sous NetBSD chezmoicamarche, ou quand ça marche pas, y a rien de méchant à régler (faut dire aussi que je suis pas un fan des trucs style KDE/Gnome ou tout ces méga-machins qui ont des dépendances dans tous les sens).
Oui, en gros tu utilises les cas super-simples ou ca marche presque toujours, quoi ;-)
Un autre GROS avantage, c'est que ca a permis d'unifier un peu tous les scripts divers des ports et packages. On n'a plus qu'une seule routine de gestion de packing-list (ecrite en perl), et ca se voit... ;-)
Juste une question: est-ce que OpenBSD tourne en DomU/dom0 sous Xen ?
pas que je sache.
totof2000
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes ces surcouches qui passent leur temps a essayer de reconstituer des informations semantiques que les couches d'en dessous ont perdu.
Tu noteras que je reproche justement à Debian/free d'ajouter des couches à un système pour pallier aux lacunes des couches du dessous. Je suis d'avis que si un système est mal fichu, ou qu'il a des lacunes, ce n'est pas en multipliant les couches par dessus qu'on va améliorer l'ensemble. Ca ne fait qu'augmenter la complexité du bazar, et tôt ou tard, ça pête.
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson
rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes
ces surcouches qui passent leur temps a essayer de reconstituer des
informations semantiques que les couches d'en dessous ont perdu.
Tu noteras que je reproche justement à Debian/free d'ajouter des couches
à un système pour pallier aux lacunes des couches du dessous. Je suis
d'avis que si un système est mal fichu, ou qu'il a des lacunes, ce n'est
pas en multipliant les couches par dessus qu'on va améliorer l'ensemble.
Ca ne fait qu'augmenter la complexité du bazar, et tôt ou tard, ça pête.
A l'arrivee, j'ai un outil compact, non atteint du syndrome du poisson rouge (je suis qui ? je vais ou ?) qui a un peu tendance a frapper toutes ces surcouches qui passent leur temps a essayer de reconstituer des informations semantiques que les couches d'en dessous ont perdu.
Tu noteras que je reproche justement à Debian/free d'ajouter des couches à un système pour pallier aux lacunes des couches du dessous. Je suis d'avis que si un système est mal fichu, ou qu'il a des lacunes, ce n'est pas en multipliant les couches par dessus qu'on va améliorer l'ensemble. Ca ne fait qu'augmenter la complexité du bazar, et tôt ou tard, ça pête.
espie
In article <4759deaa$0$8671$, totof2000 wrote:
Tu noteras que je reproche justement à Debian/free d'ajouter des couches à un système pour pallier aux lacunes des couches du dessous. Je suis d'avis que si un système est mal fichu, ou qu'il a des lacunes, ce n'est pas en multipliant les couches par dessus qu'on va améliorer l'ensemble. Ca ne fait qu'augmenter la complexité du bazar, et tôt ou tard, ça pête.
Le vieux pkg_add en C est lui-meme atteint du syndrome du poisson rouge, puisqu'il s'appelle lui-meme pour gerer les dependances, ce qui fait que sur un ensemble de sous-packages, on recalcule les dependances a chaque sous-package. C'est d'ailleurs un peu ce qui a conduit netbsd a introduire une `vraie' base de donnees pour /var/db/pkg: ca ramait trop... (avec les problemes que ca comporte si la base de donnees se desynchronise, ce qui malheureusement peut arriver, et la necessite d'avoir un outil pour reconstruire celle-ci).
In article <4759deaa$0$8671$426a74cc@news.free.fr>,
totof2000 <nospam@nospam.org> wrote:
Tu noteras que je reproche justement à Debian/free d'ajouter des couches
à un système pour pallier aux lacunes des couches du dessous. Je suis
d'avis que si un système est mal fichu, ou qu'il a des lacunes, ce n'est
pas en multipliant les couches par dessus qu'on va améliorer l'ensemble.
Ca ne fait qu'augmenter la complexité du bazar, et tôt ou tard, ça pête.
Le vieux pkg_add en C est lui-meme atteint du syndrome du poisson rouge,
puisqu'il s'appelle lui-meme pour gerer les dependances, ce qui fait
que sur un ensemble de sous-packages, on recalcule les dependances a
chaque sous-package. C'est d'ailleurs un peu ce qui a conduit netbsd
a introduire une `vraie' base de donnees pour /var/db/pkg: ca ramait
trop... (avec les problemes que ca comporte si la base de donnees se
desynchronise, ce qui malheureusement peut arriver, et la necessite
d'avoir un outil pour reconstruire celle-ci).
Tu noteras que je reproche justement à Debian/free d'ajouter des couches à un système pour pallier aux lacunes des couches du dessous. Je suis d'avis que si un système est mal fichu, ou qu'il a des lacunes, ce n'est pas en multipliant les couches par dessus qu'on va améliorer l'ensemble. Ca ne fait qu'augmenter la complexité du bazar, et tôt ou tard, ça pête.
Le vieux pkg_add en C est lui-meme atteint du syndrome du poisson rouge, puisqu'il s'appelle lui-meme pour gerer les dependances, ce qui fait que sur un ensemble de sous-packages, on recalcule les dependances a chaque sous-package. C'est d'ailleurs un peu ce qui a conduit netbsd a introduire une `vraie' base de donnees pour /var/db/pkg: ca ramait trop... (avec les problemes que ca comporte si la base de donnees se desynchronise, ce qui malheureusement peut arriver, et la necessite d'avoir un outil pour reconstruire celle-ci).
totof2000
D'ailleurs, ton `ca marche'. bof. Il y a encore pas mal de problemes... je suis suffisamment les ml de netbsd pour les voir... Globalement, pour les mise-a-jour, vous etes encore pas mal en mode `on enleve les vieux trucs et on installe les nouveaux', ce qui est souvent pas mal couteux.
Je sais pas trop: pour les packages que j'utilise, un simple pkg_add -v -u -u passe dans la plupart des cas. J'ai peut-être eu à une époque des soucis sur certains trucs, mais ça ne m'a pas marqué.
Oui, en gros tu utilises les cas super-simples ou ca marche presque toujours, quoi ;-)
Disons que je n'aime pas me compliquer la vie, et que lorsque j'ai un besoin précis, je cherche à y répondre par la solution la plus simple. Je me moque un peu de l'apparence de mon desktop, qu'OpenOffice n'a pas le même look&feel que mon bureau, ou ce genre de choses.
D'ailleurs, ton `ca marche'. bof. Il y a encore pas mal de problemes...
je suis suffisamment les ml de netbsd pour les voir... Globalement, pour
les mise-a-jour, vous etes encore pas mal en mode `on enleve les vieux
trucs et on installe les nouveaux', ce qui est souvent pas mal couteux.
Je sais pas trop: pour les packages que j'utilise, un simple pkg_add -v
-u -u passe dans la plupart des cas. J'ai peut-être eu à une époque des
soucis sur certains trucs, mais ça ne m'a pas marqué.
Oui, en gros tu utilises les cas super-simples ou ca marche presque toujours,
quoi ;-)
Disons que je n'aime pas me compliquer la vie, et que lorsque j'ai un
besoin précis, je cherche à y répondre par la solution la plus simple.
Je me moque un peu de l'apparence de mon desktop, qu'OpenOffice n'a pas
le même look&feel que mon bureau, ou ce genre de choses.
D'ailleurs, ton `ca marche'. bof. Il y a encore pas mal de problemes... je suis suffisamment les ml de netbsd pour les voir... Globalement, pour les mise-a-jour, vous etes encore pas mal en mode `on enleve les vieux trucs et on installe les nouveaux', ce qui est souvent pas mal couteux.
Je sais pas trop: pour les packages que j'utilise, un simple pkg_add -v -u -u passe dans la plupart des cas. J'ai peut-être eu à une époque des soucis sur certains trucs, mais ça ne m'a pas marqué.
Oui, en gros tu utilises les cas super-simples ou ca marche presque toujours, quoi ;-)
Disons que je n'aime pas me compliquer la vie, et que lorsque j'ai un besoin précis, je cherche à y répondre par la solution la plus simple. Je me moque un peu de l'apparence de mon desktop, qu'OpenOffice n'a pas le même look&feel que mon bureau, ou ce genre de choses.
espie
In article <4759e0e7$0$10267$, totof2000 wrote:
Oui, en gros tu utilises les cas super-simples ou ca marche presque toujours, quoi ;-)
Disons que je n'aime pas me compliquer la vie, et que lorsque j'ai un besoin précis, je cherche à y répondre par la solution la plus simple. Je me moque un peu de l'apparence de mon desktop, qu'OpenOffice n'a pas le même look&feel que mon bureau, ou ce genre de choses.
Ben disons que moi, j'ai passe du temps pour que les gens n'aient pas a se compliquer la vie, et que ca fonctionne du premier coup dans >99% des cas...
In article <4759e0e7$0$10267$426a74cc@news.free.fr>,
totof2000 <nospam@nospam.org> wrote:
Oui, en gros tu utilises les cas super-simples ou ca marche presque toujours,
quoi ;-)
Disons que je n'aime pas me compliquer la vie, et que lorsque j'ai un
besoin précis, je cherche à y répondre par la solution la plus simple.
Je me moque un peu de l'apparence de mon desktop, qu'OpenOffice n'a pas
le même look&feel que mon bureau, ou ce genre de choses.
Ben disons que moi, j'ai passe du temps pour que les gens n'aient pas
a se compliquer la vie, et que ca fonctionne du premier coup dans >99%
des cas...
Oui, en gros tu utilises les cas super-simples ou ca marche presque toujours, quoi ;-)
Disons que je n'aime pas me compliquer la vie, et que lorsque j'ai un besoin précis, je cherche à y répondre par la solution la plus simple. Je me moque un peu de l'apparence de mon desktop, qu'OpenOffice n'a pas le même look&feel que mon bureau, ou ce genre de choses.
Ben disons que moi, j'ai passe du temps pour que les gens n'aient pas a se compliquer la vie, et que ca fonctionne du premier coup dans >99% des cas...
totof2000
Marc Espie wrote:
Le vieux pkg_add en C est lui-meme atteint du syndrome du poisson rouge, puisqu'il s'appelle lui-meme pour gerer les dependances, ce qui fait que sur un ensemble de sous-packages, on recalcule les dependances a chaque sous-package. C'est d'ailleurs un peu ce qui a conduit netbsd a introduire une `vraie' base de donnees pour /var/db/pkg: ca ramait trop... (avec les problemes que ca comporte si la base de donnees se desynchronise, ce qui malheureusement peut arriver, et la necessite d'avoir un outil pour reconstruire celle-ci).
C'est effectivement un problème que j'ai rencontré à une époque, mais c'était du à une mauvaise manip de ma part. Autre problème rencontré: un package qui nécessite une version d'un autre package >= à n, mais qui n'est pas capable de se rendre compte que la version installée du package est la n+2. Mais comme ça ne m'est pas arrivé souvent, je ne me rend pas trop compte ....
Marc Espie wrote:
Le vieux pkg_add en C est lui-meme atteint du syndrome du poisson rouge,
puisqu'il s'appelle lui-meme pour gerer les dependances, ce qui fait
que sur un ensemble de sous-packages, on recalcule les dependances a
chaque sous-package. C'est d'ailleurs un peu ce qui a conduit netbsd
a introduire une `vraie' base de donnees pour /var/db/pkg: ca ramait
trop... (avec les problemes que ca comporte si la base de donnees se
desynchronise, ce qui malheureusement peut arriver, et la necessite
d'avoir un outil pour reconstruire celle-ci).
C'est effectivement un problème que j'ai rencontré à une époque, mais
c'était du à une mauvaise manip de ma part. Autre problème rencontré: un
package qui nécessite une version d'un autre package >= à n, mais qui
n'est pas capable de se rendre compte que la version installée du
package est la n+2. Mais comme ça ne m'est pas arrivé souvent, je ne me
rend pas trop compte ....
Le vieux pkg_add en C est lui-meme atteint du syndrome du poisson rouge, puisqu'il s'appelle lui-meme pour gerer les dependances, ce qui fait que sur un ensemble de sous-packages, on recalcule les dependances a chaque sous-package. C'est d'ailleurs un peu ce qui a conduit netbsd a introduire une `vraie' base de donnees pour /var/db/pkg: ca ramait trop... (avec les problemes que ca comporte si la base de donnees se desynchronise, ce qui malheureusement peut arriver, et la necessite d'avoir un outil pour reconstruire celle-ci).
C'est effectivement un problème que j'ai rencontré à une époque, mais c'était du à une mauvaise manip de ma part. Autre problème rencontré: un package qui nécessite une version d'un autre package >= à n, mais qui n'est pas capable de se rendre compte que la version installée du package est la n+2. Mais comme ça ne m'est pas arrivé souvent, je ne me rend pas trop compte ....
