[OpenBSD] pkg_add et autres (etait Re: [FreeBSD] Update)
5 réponses
Serge Basterot
On 2005-03-12, Marc Espie <espie@tetto.home> wrote:
[...]
> Et on commence a avoir des outils de mise-a-jour propres, e.g., qui
> comprennent directement les problemes de bibliotheques partagees et
> de dependances entre packages sans avoir a passer par une usine a
> gaz qui risque de desinstaller toute la machine par megarde...
D'ailleurs où il en est le pkg_add -r ? Sera-t-il pleinement utilisable
en mai ? J'ai pas encore essayé de l'utiliser, mes sources sont
seulement celles de la page de man du dernier snapshot que j'ai
installé qui dit que c'est encore expérimental.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
espie
In article , Serge Basterot wrote:
On 2005-03-12, Marc Espie wrote:
[...]
Et on commence a avoir des outils de mise-a-jour propres, e.g., qui comprennent directement les problemes de bibliotheques partagees et de dependances entre packages sans avoir a passer par une usine a gaz qui risque de desinstaller toute la machine par megarde...
D'ailleurs où il en est le pkg_add -r ? Sera-t-il pleinement utilisable en mai ? J'ai pas encore essayé de l'utiliser, mes sources sont seulement celles de la page de man du dernier snapshot que j'ai installé qui dit que c'est encore expérimental.
Ca fonctionne dans 99% des cas. C'est l'outil `de base', il faut toujours lui dire tres precisement tous les intitules de packages que tu veux remplacer, mais il sait faire (en mode -r, pkg_add reordonne proprement tous les packages que tu veux mettre a jour, et donc tu peux faire une mise a jour globale sans casse).
Il y a des choses qu'il ne fait pas encore, comme d'etre capable de remplacer globalement foo-1.0 et bar-1.0 par foo-1.1 et bar-1.1 sous pretexte qu'un fichier est passe de foo a bar dans la mise-a-jour (en ce moment, pkg_add -r triche legerement, et va te desinstaller foo-1.0 et bar-1.0 pour remplacer par foo-1.1, puis installer bar-1.1, ce qui fait que ca PEUT s'arreter avec juste foo-1.1 installe). C'etait pas prevu, mais ca se produit dans la vraie vie: entre 3.6 et 3.7, qt3-base/qt3-mt et kdelibs/kdebase sont concernees.
on a pas mal de packages pour lesquels les dependances sont trop strictes. C'est prevu de passer les run_depends par defaut de pkgname-version vers pkgname-* apres la 3.7, et il y aura des verifs a faire.
Il y a eu un audit monstrueux de toutes les dependances de bibliotheques partagees, qui a trouve quelques dependances cachees et a corrige plein de petits details, la base de packages est propre aujourd'hui.
En gros, sur les packages du CD, il n'y a guere que mozilla qu'il ne sache pas mettre a jour, le script de deinstall etant monumentalement buggue... Je sais comment corriger, faut juste que je teste (ca prend du temps vu la taille du lezard... c'est tout con, c'est juste l'API qui a change avec le passage de gcc 2.95 a gcc 3.3, donc faut mettre un numero de version sur le repertoire d'extensions, ce cretin de programme etant infoutu de le faire lui-meme).
En tout cas, ca fait quelques mois que je fais tous mes builds de packages sans rien desinstaller et en utilisant make update FORCE_UPDATE=Yes, et il ne reste aucun probleme majeur.
Les trucs qui manquent sont prevus pour apres la 3.7: le coup des mises a jour petit groupe de packages par petit groupe de packages est une grosse modif un peu trop destabilisante pour la faire maintenant, et la determination automatique des noms de packages a mettre a jour necessite de revoir tout le module de recuperation de packages par ftp (le probleme etant qu'on ne peut avoir plus d'une connexion ftp sur un site ouverte a la fois, comme pas mal de sites ont des limiteurs de nombre de connexions par adresse IP).
Le plus par rapport aux voisins, c'est qu'on sait maintenant mettre a jour des packages de facon fiable et sure sans avoir a desinstaller les 3/4 de la machine. Quasiment tous les autres systemes de packages ont choisi un systeme transactionnel: on essaie de mettre a jour, et si ca foire, on revient en arriere. Nous, on a une approche semantique: on calcule la mise-a-jour, si le calcul repond okay, on fait la mise-a-jour (qui ne peut pas foirer) et si elle foire quand meme, on revient sur du transactionnel. L'orientation `calcul' fait que le systeme de packages se debarrasse de tous ses scripts d'install, qui sont remplaces par des mecanismes generiques ET simulables au sein de pkg_add. Le systme de gestion de packages vise a avoir une connaissance totale de haut niveau de ce qu'il faut faire pour une mise a jour...
Et ca marche bien: c'est vachement plus simple de debugguer une petite infrastructure en 1 exemplaire, que 2000 scripts d'installs differents plus ou moins clones a partir du meme template mal foutu...
In article <slrnd38355.9ob.sergeNOSP@poufy.gakoz.net>,
Serge Basterot <sergeNOSP@Mblouk.net> wrote:
On 2005-03-12, Marc Espie <espie@tetto.home> wrote:
[...]
Et on commence a avoir des outils de mise-a-jour propres, e.g., qui
comprennent directement les problemes de bibliotheques partagees et
de dependances entre packages sans avoir a passer par une usine a
gaz qui risque de desinstaller toute la machine par megarde...
D'ailleurs où il en est le pkg_add -r ? Sera-t-il pleinement utilisable
en mai ? J'ai pas encore essayé de l'utiliser, mes sources sont
seulement celles de la page de man du dernier snapshot que j'ai
installé qui dit que c'est encore expérimental.
Ca fonctionne dans 99% des cas.
C'est l'outil `de base', il faut toujours lui dire tres precisement
tous les intitules de packages que tu veux remplacer, mais il sait faire
(en mode -r, pkg_add reordonne proprement tous les packages que tu veux mettre
a jour, et donc tu peux faire une mise a jour globale sans casse).
Il y a des choses qu'il ne fait pas encore, comme d'etre capable
de remplacer globalement foo-1.0 et bar-1.0 par foo-1.1 et bar-1.1 sous
pretexte qu'un fichier est passe de foo a bar dans la mise-a-jour
(en ce moment, pkg_add -r triche legerement, et va te desinstaller foo-1.0
et bar-1.0 pour remplacer par foo-1.1, puis installer bar-1.1, ce qui fait
que ca PEUT s'arreter avec juste foo-1.1 installe). C'etait pas prevu,
mais ca se produit dans la vraie vie: entre 3.6 et 3.7, qt3-base/qt3-mt
et kdelibs/kdebase sont concernees.
on a pas mal de packages pour lesquels les dependances sont trop strictes.
C'est prevu de passer les run_depends par defaut de pkgname-version vers
pkgname-* apres la 3.7, et il y aura des verifs a faire.
Il y a eu un audit monstrueux de toutes les dependances de bibliotheques
partagees, qui a trouve quelques dependances cachees et a corrige plein
de petits details, la base de packages est propre aujourd'hui.
En gros, sur les packages du CD, il n'y a guere que mozilla qu'il ne sache
pas mettre a jour, le script de deinstall etant monumentalement buggue...
Je sais comment corriger, faut juste que je teste (ca prend du temps vu la
taille du lezard... c'est tout con, c'est juste l'API qui a change avec
le passage de gcc 2.95 a gcc 3.3, donc faut mettre un numero de version
sur le repertoire d'extensions, ce cretin de programme etant infoutu de
le faire lui-meme).
En tout cas, ca fait quelques mois que je fais tous mes builds de packages
sans rien desinstaller et en utilisant make update FORCE_UPDATE=Yes, et
il ne reste aucun probleme majeur.
Les trucs qui manquent sont prevus pour apres la 3.7: le coup des mises
a jour petit groupe de packages par petit groupe de packages est une grosse
modif un peu trop destabilisante pour la faire maintenant, et la
determination automatique des noms de packages a mettre a jour necessite
de revoir tout le module de recuperation de packages par ftp (le probleme
etant qu'on ne peut avoir plus d'une connexion ftp sur un site ouverte a la
fois, comme pas mal de sites ont des limiteurs de nombre de connexions par
adresse IP).
Le plus par rapport aux voisins, c'est qu'on sait maintenant mettre a jour
des packages de facon fiable et sure sans avoir a desinstaller les 3/4 de
la machine. Quasiment tous les autres systemes de packages ont choisi
un systeme transactionnel: on essaie de mettre a jour, et si ca foire, on
revient en arriere. Nous, on a une approche semantique: on calcule la
mise-a-jour, si le calcul repond okay, on fait la mise-a-jour (qui ne peut
pas foirer) et si elle foire quand meme, on revient sur du transactionnel.
L'orientation `calcul' fait que le systeme de packages se debarrasse de tous
ses scripts d'install, qui sont remplaces par des mecanismes generiques ET
simulables au sein de pkg_add. Le systme de gestion de packages vise a avoir
une connaissance totale de haut niveau de ce qu'il faut faire pour une mise
a jour...
Et ca marche bien: c'est vachement plus simple de debugguer une petite
infrastructure en 1 exemplaire, que 2000 scripts d'installs differents plus
ou moins clones a partir du meme template mal foutu...
Et on commence a avoir des outils de mise-a-jour propres, e.g., qui comprennent directement les problemes de bibliotheques partagees et de dependances entre packages sans avoir a passer par une usine a gaz qui risque de desinstaller toute la machine par megarde...
D'ailleurs où il en est le pkg_add -r ? Sera-t-il pleinement utilisable en mai ? J'ai pas encore essayé de l'utiliser, mes sources sont seulement celles de la page de man du dernier snapshot que j'ai installé qui dit que c'est encore expérimental.
Ca fonctionne dans 99% des cas. C'est l'outil `de base', il faut toujours lui dire tres precisement tous les intitules de packages que tu veux remplacer, mais il sait faire (en mode -r, pkg_add reordonne proprement tous les packages que tu veux mettre a jour, et donc tu peux faire une mise a jour globale sans casse).
Il y a des choses qu'il ne fait pas encore, comme d'etre capable de remplacer globalement foo-1.0 et bar-1.0 par foo-1.1 et bar-1.1 sous pretexte qu'un fichier est passe de foo a bar dans la mise-a-jour (en ce moment, pkg_add -r triche legerement, et va te desinstaller foo-1.0 et bar-1.0 pour remplacer par foo-1.1, puis installer bar-1.1, ce qui fait que ca PEUT s'arreter avec juste foo-1.1 installe). C'etait pas prevu, mais ca se produit dans la vraie vie: entre 3.6 et 3.7, qt3-base/qt3-mt et kdelibs/kdebase sont concernees.
on a pas mal de packages pour lesquels les dependances sont trop strictes. C'est prevu de passer les run_depends par defaut de pkgname-version vers pkgname-* apres la 3.7, et il y aura des verifs a faire.
Il y a eu un audit monstrueux de toutes les dependances de bibliotheques partagees, qui a trouve quelques dependances cachees et a corrige plein de petits details, la base de packages est propre aujourd'hui.
En gros, sur les packages du CD, il n'y a guere que mozilla qu'il ne sache pas mettre a jour, le script de deinstall etant monumentalement buggue... Je sais comment corriger, faut juste que je teste (ca prend du temps vu la taille du lezard... c'est tout con, c'est juste l'API qui a change avec le passage de gcc 2.95 a gcc 3.3, donc faut mettre un numero de version sur le repertoire d'extensions, ce cretin de programme etant infoutu de le faire lui-meme).
En tout cas, ca fait quelques mois que je fais tous mes builds de packages sans rien desinstaller et en utilisant make update FORCE_UPDATE=Yes, et il ne reste aucun probleme majeur.
Les trucs qui manquent sont prevus pour apres la 3.7: le coup des mises a jour petit groupe de packages par petit groupe de packages est une grosse modif un peu trop destabilisante pour la faire maintenant, et la determination automatique des noms de packages a mettre a jour necessite de revoir tout le module de recuperation de packages par ftp (le probleme etant qu'on ne peut avoir plus d'une connexion ftp sur un site ouverte a la fois, comme pas mal de sites ont des limiteurs de nombre de connexions par adresse IP).
Le plus par rapport aux voisins, c'est qu'on sait maintenant mettre a jour des packages de facon fiable et sure sans avoir a desinstaller les 3/4 de la machine. Quasiment tous les autres systemes de packages ont choisi un systeme transactionnel: on essaie de mettre a jour, et si ca foire, on revient en arriere. Nous, on a une approche semantique: on calcule la mise-a-jour, si le calcul repond okay, on fait la mise-a-jour (qui ne peut pas foirer) et si elle foire quand meme, on revient sur du transactionnel. L'orientation `calcul' fait que le systeme de packages se debarrasse de tous ses scripts d'install, qui sont remplaces par des mecanismes generiques ET simulables au sein de pkg_add. Le systme de gestion de packages vise a avoir une connaissance totale de haut niveau de ce qu'il faut faire pour une mise a jour...
Et ca marche bien: c'est vachement plus simple de debugguer une petite infrastructure en 1 exemplaire, que 2000 scripts d'installs differents plus ou moins clones a partir du meme template mal foutu...
espie
In article <d13o79$pl4$, Marc Espie wrote:
In article , Serge Basterot wrote:
D'ailleurs où il en est le pkg_add -r ? Sera-t-il pleinement utilisable en mai ? J'ai pas encore essayé de l'utiliser, mes sources sont seulement celles de la page de man du dernier snapshot que j'ai installé qui dit que c'est encore expérimental.
Ca fonctionne dans 99% des cas.
Et j'ajouterai que ca restera marque comme experimental. 99% des cas, ca n'est pas du 100%. C'est tres utilisable en pratique, mais tant qu'il y a des exceptions non gerees, ca reste de l'experimental pour moi.
In article <d13o79$pl4$1@biggoron.nerim.net>,
Marc Espie <espie@nerim.net> wrote:
In article <slrnd38355.9ob.sergeNOSP@poufy.gakoz.net>,
Serge Basterot <sergeNOSP@Mblouk.net> wrote:
D'ailleurs où il en est le pkg_add -r ? Sera-t-il pleinement utilisable
en mai ? J'ai pas encore essayé de l'utiliser, mes sources sont
seulement celles de la page de man du dernier snapshot que j'ai
installé qui dit que c'est encore expérimental.
Ca fonctionne dans 99% des cas.
Et j'ajouterai que ca restera marque comme experimental. 99% des cas,
ca n'est pas du 100%. C'est tres utilisable en pratique, mais tant qu'il
y a des exceptions non gerees, ca reste de l'experimental pour moi.
D'ailleurs où il en est le pkg_add -r ? Sera-t-il pleinement utilisable en mai ? J'ai pas encore essayé de l'utiliser, mes sources sont seulement celles de la page de man du dernier snapshot que j'ai installé qui dit que c'est encore expérimental.
Ca fonctionne dans 99% des cas.
Et j'ajouterai que ca restera marque comme experimental. 99% des cas, ca n'est pas du 100%. C'est tres utilisable en pratique, mais tant qu'il y a des exceptions non gerees, ca reste de l'experimental pour moi.
Serge Basterot
On 2005-03-14, Marc Espie wrote:
On 2005-03-12, Marc Espie wrote:
[snip]
Et ca marche bien: c'est vachement plus simple de debugguer une petite infrastructure en 1 exemplaire, que 2000 scripts d'installs differents plus ou moins clones a partir du meme template mal foutu...
Ça, c'est de la réponse qu'elle est clair, complète et précise. Merci. Bon ben j'ai plus qu'à jouer avec pkg_add :-)
-- Serge
On 2005-03-14, Marc Espie <espie@tetto.home> wrote:
On 2005-03-12, Marc Espie <espie@tetto.home> wrote:
[snip]
Et ca marche bien: c'est vachement plus simple de debugguer une petite
infrastructure en 1 exemplaire, que 2000 scripts d'installs differents plus
ou moins clones a partir du meme template mal foutu...
Ça, c'est de la réponse qu'elle est clair, complète et précise. Merci.
Bon ben j'ai plus qu'à jouer avec pkg_add :-)
Et ca marche bien: c'est vachement plus simple de debugguer une petite infrastructure en 1 exemplaire, que 2000 scripts d'installs differents plus ou moins clones a partir du meme template mal foutu...
Ça, c'est de la réponse qu'elle est clair, complète et précise. Merci. Bon ben j'ai plus qu'à jouer avec pkg_add :-)
-- Serge
talon
Marc Espie wrote:
Le plus par rapport aux voisins, c'est qu'on sait maintenant mettre a jour des packages de facon fiable et sure sans avoir a desinstaller les 3/4 de la machine.
Et tu as testé ça sur Gnome par exemple? Les trucs trop beaux pour qu'on puisse les croire, à mon age, justement on y croit plus beaucoup. Il y a aussi des gens qui prétendent que portupgrade marche. Si on le fait tourner tous les jours et qu'on oublie les cas où ça a merdé, peut être. Si on essaye de mettre à jour sa bécane sans y avoir touché depuis un an, on trouve comme il fallait s'y attendre que rien ne marche. Quand aux "audits monstres de ports", quand il y en aura plus de 10 000 dans OpenBSD tu verras si tu arrives à les faire, à t'assurer que les mainteneurs de ports n'ont pas mis des dépendances trop strictes qui mettent le bazar partout, etc. Il suffit de voir le temps que Debian Sarge met à sortit pour comprendre que l'illusion d'un système de paquetage qui marche n'est rien d'autre justement qu'une illusion. Le temps que tu mettes tout au point pour qu'il n'y ait plus d'incompatibilité, tout est périmé.
--
Michel TALON
Marc Espie <espie@tetto.home> wrote:
Le plus par rapport aux voisins, c'est qu'on sait maintenant mettre a jour
des packages de facon fiable et sure sans avoir a desinstaller les 3/4 de
la machine.
Et tu as testé ça sur Gnome par exemple? Les trucs trop beaux pour qu'on
puisse les croire, à mon age, justement on y croit plus beaucoup.
Il y a aussi des gens qui prétendent que portupgrade marche. Si
on le fait tourner tous les jours et qu'on oublie les cas où ça a merdé,
peut être. Si on essaye de mettre à jour sa bécane sans y avoir touché depuis
un an, on trouve comme il fallait s'y attendre que rien ne marche.
Quand aux "audits monstres de ports", quand il y en aura plus de 10 000 dans
OpenBSD tu verras si tu arrives à les faire, à t'assurer que les mainteneurs
de ports n'ont pas mis des dépendances trop strictes qui mettent le bazar
partout, etc. Il suffit de voir le temps que Debian Sarge met à sortit pour
comprendre que l'illusion d'un système de paquetage qui marche n'est rien
d'autre justement qu'une illusion. Le temps que tu mettes tout au point pour
qu'il n'y ait plus d'incompatibilité, tout est périmé.
Le plus par rapport aux voisins, c'est qu'on sait maintenant mettre a jour des packages de facon fiable et sure sans avoir a desinstaller les 3/4 de la machine.
Et tu as testé ça sur Gnome par exemple? Les trucs trop beaux pour qu'on puisse les croire, à mon age, justement on y croit plus beaucoup. Il y a aussi des gens qui prétendent que portupgrade marche. Si on le fait tourner tous les jours et qu'on oublie les cas où ça a merdé, peut être. Si on essaye de mettre à jour sa bécane sans y avoir touché depuis un an, on trouve comme il fallait s'y attendre que rien ne marche. Quand aux "audits monstres de ports", quand il y en aura plus de 10 000 dans OpenBSD tu verras si tu arrives à les faire, à t'assurer que les mainteneurs de ports n'ont pas mis des dépendances trop strictes qui mettent le bazar partout, etc. Il suffit de voir le temps que Debian Sarge met à sortit pour comprendre que l'illusion d'un système de paquetage qui marche n'est rien d'autre justement qu'une illusion. Le temps que tu mettes tout au point pour qu'il n'y ait plus d'incompatibilité, tout est périmé.
--
Michel TALON
espie
In article <d1418t$gdb$, Michel Talon wrote:
Marc Espie wrote:
Le plus par rapport aux voisins, c'est qu'on sait maintenant mettre a jour des packages de facon fiable et sure sans avoir a desinstaller les 3/4 de la machine.
Et tu as testé ça sur Gnome par exemple? Les trucs trop beaux pour qu'on puisse les croire, à mon age, justement on y croit plus beaucoup.
Oui, ca se passe plutot bien sur gnome ou kde.
Quand aux "audits monstres de ports", quand il y en aura plus de 10 000 dans OpenBSD tu verras si tu arrives à les faire, à t'assurer que les mainteneurs de ports n'ont pas mis des dépendances trop strictes qui mettent le bazar partout, etc. Il suffit de voir le temps que Debian Sarge met à sortit pour comprendre que l'illusion d'un système de paquetage qui marche n'est rien d'autre justement qu'une illusion. Le temps que tu mettes tout au point pour qu'il n'y ait plus d'incompatibilité, tout est périmé.
Il y a un ensemble de raisons pour lesquelles je doute qu'on ait 10000 ports avant assez longtemps. Typiquement, on ne passe pas notre temps a essayer d'avoir la granularite la plus petite possible, ni a avoir 4000000 d'options de compilation. Je pense par exemple que tous les systemes qui s'amusent a redecouper kde en petits morceaux n'ont rien compris. Ca serait plus important de corriger les quelques bugs qui trainent.
Sinon, on ne met pas dans les ports tous les logiciels a moitie finis. Ca gagne aussi de la place. C'est vrai qu'il nous manque des trucs mais on ajoute petit a petit (style, on finira bien par avoir OpenOffice, je sais plus quel machin de montage video, blast, clanlib et quelques autres trucs).
Mais cote infrastructure, on essaie de pondre des solutions generiques, SIMPLES, et applicables partout. De temps en temps, ca bouffe du temps, parce qu'on decouvre que la solution heritee des voisins n'est pas acceptable (genre la gestion des dependances), mais on s'en sort tres bien compte tenu de la taille de notre equipe.
On a aussi en cours un GROS boulot de documentation de l'infrastructure, justement. Pour que les choses simples soient faites simplement, et que les choses compliquees restent faisables....
In article <d1418t$gdb$1@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Marc Espie <espie@tetto.home> wrote:
Le plus par rapport aux voisins, c'est qu'on sait maintenant mettre a jour
des packages de facon fiable et sure sans avoir a desinstaller les 3/4 de
la machine.
Et tu as testé ça sur Gnome par exemple? Les trucs trop beaux pour qu'on
puisse les croire, à mon age, justement on y croit plus beaucoup.
Oui, ca se passe plutot bien sur gnome ou kde.
Quand aux "audits monstres de ports", quand il y en aura plus de 10 000 dans
OpenBSD tu verras si tu arrives à les faire, à t'assurer que les mainteneurs
de ports n'ont pas mis des dépendances trop strictes qui mettent le bazar
partout, etc. Il suffit de voir le temps que Debian Sarge met à sortit pour
comprendre que l'illusion d'un système de paquetage qui marche n'est rien
d'autre justement qu'une illusion. Le temps que tu mettes tout au point pour
qu'il n'y ait plus d'incompatibilité, tout est périmé.
Il y a un ensemble de raisons pour lesquelles je doute qu'on ait 10000 ports
avant assez longtemps. Typiquement, on ne passe pas notre temps a essayer
d'avoir la granularite la plus petite possible, ni a avoir 4000000 d'options
de compilation. Je pense par exemple que tous les systemes qui s'amusent a
redecouper kde en petits morceaux n'ont rien compris. Ca serait plus important
de corriger les quelques bugs qui trainent.
Sinon, on ne met pas dans les ports tous les logiciels a moitie finis. Ca
gagne aussi de la place. C'est vrai qu'il nous manque des trucs mais on
ajoute petit a petit (style, on finira bien par avoir OpenOffice, je sais plus
quel machin de montage video, blast, clanlib et quelques autres trucs).
Mais cote infrastructure, on essaie de pondre des solutions generiques,
SIMPLES, et applicables partout. De temps en temps, ca bouffe du temps,
parce qu'on decouvre que la solution heritee des voisins n'est pas
acceptable (genre la gestion des dependances), mais on s'en sort tres bien
compte tenu de la taille de notre equipe.
On a aussi en cours un GROS boulot de documentation de l'infrastructure,
justement. Pour que les choses simples soient faites simplement, et que les
choses compliquees restent faisables....
Le plus par rapport aux voisins, c'est qu'on sait maintenant mettre a jour des packages de facon fiable et sure sans avoir a desinstaller les 3/4 de la machine.
Et tu as testé ça sur Gnome par exemple? Les trucs trop beaux pour qu'on puisse les croire, à mon age, justement on y croit plus beaucoup.
Oui, ca se passe plutot bien sur gnome ou kde.
Quand aux "audits monstres de ports", quand il y en aura plus de 10 000 dans OpenBSD tu verras si tu arrives à les faire, à t'assurer que les mainteneurs de ports n'ont pas mis des dépendances trop strictes qui mettent le bazar partout, etc. Il suffit de voir le temps que Debian Sarge met à sortit pour comprendre que l'illusion d'un système de paquetage qui marche n'est rien d'autre justement qu'une illusion. Le temps que tu mettes tout au point pour qu'il n'y ait plus d'incompatibilité, tout est périmé.
Il y a un ensemble de raisons pour lesquelles je doute qu'on ait 10000 ports avant assez longtemps. Typiquement, on ne passe pas notre temps a essayer d'avoir la granularite la plus petite possible, ni a avoir 4000000 d'options de compilation. Je pense par exemple que tous les systemes qui s'amusent a redecouper kde en petits morceaux n'ont rien compris. Ca serait plus important de corriger les quelques bugs qui trainent.
Sinon, on ne met pas dans les ports tous les logiciels a moitie finis. Ca gagne aussi de la place. C'est vrai qu'il nous manque des trucs mais on ajoute petit a petit (style, on finira bien par avoir OpenOffice, je sais plus quel machin de montage video, blast, clanlib et quelques autres trucs).
Mais cote infrastructure, on essaie de pondre des solutions generiques, SIMPLES, et applicables partout. De temps en temps, ca bouffe du temps, parce qu'on decouvre que la solution heritee des voisins n'est pas acceptable (genre la gestion des dependances), mais on s'en sort tres bien compte tenu de la taille de notre equipe.
On a aussi en cours un GROS boulot de documentation de l'infrastructure, justement. Pour que les choses simples soient faites simplement, et que les choses compliquees restent faisables....
