NetBSD , etat des lieux.

Il faut noter que l'agreement a une importance précise dans la mesure où
TNF est titulaire du copyright d'une grande partie du code. D'accord,
ça n'empêche pas nos grands amis d'OpenBSD d'attribuer le copyright à
TNF pour du code d'origine pas forcément connue (du point de vue de TNF,
j'entends).

Peux-tu préciser ta pensée ?

Miod Vallat <miod@online.fr> wrote:

Il faut noter que l'agreement a une importance précise dans la mesure où
TNF est titulaire du copyright d'une grande partie du code. D'accord,
ça n'empêche pas nos grands amis d'OpenBSD d'attribuer le copyright à
TNF pour du code d'origine pas forcément connue (du point de vue de TNF,
j'entends).
Peux-tu préciser ta pensée ?

Oui, moi aussi j'ai pas très bien compris ce qu'il voulait dire.

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org

Il faut noter que l'agreement a une importance précise dans la mesure où
TNF est titulaire du copyright d'une grande partie du code. D'accord,
ça n'empêche pas nos grands amis d'OpenBSD d'attribuer le copyright à
TNF pour du code d'origine pas forcément connue (du point de vue de TNF,
j'entends).
Peux-tu préciser ta pensée ?

Oui, moi aussi j'ai pas très bien compris ce qu'il voulait dire.

Je pense qu'il évoque la situation d'un fichier (c) TNF importé chez

OpenBSD, puis subissant des petites modifications ne méritant pas
d'ajouter un copyright supplémentaire au fichier. On se retrouve avec un
fichier marqué uniquement (c) TNF mais dont TNF n'a pas fournit tout le
code, stricto sensu.

Est-ce bien celà qu'il fallait comprendre ?

[désolé d'être en retard dans la discussion, je déménageais]

Dans l'article <mn.22957d6928a2dc94.30736@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> disait :

Mais faire signer un papier, je ne sais pas, à mes yeux cela a un
petit côté contrat, même si ce n'en est pas un, un "voilà, à partir de
maintenant c'est du sérieux ce que vous allez faire, alors attention".
Un peu normal du coup que l'un des pères fondateurs du projet n'ait pas
envie de signer. Depuis le temps il a largement prouvé qu'il se

Euh, la FSF demande depuis quasiment l'origine qu'un développeur _doit_ signer
un papier donnant les droits de son code à la FSF pour que la notion de
copyleft s'applique...

Donc, ça n'a rien de nouveau.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !

Dans l'article <1hlftkb.1pbhnl8n0960dN%manu@netbsd.org>,
Emmanuel Dreyfus <manu@netbsd.org> disait :

Benoit Izac <use.reply.to@INVALID.ADDRESS> wrote:

-- BSD n'est pas fait pour l'utilisateur lambda.

Hélàs je penche pour cette solution. Il y aurait un gros travail de
packaging et de pre-configuration des applis de bureautique pour qu'un
BSD soit lambda-friendly.

Ca existe déjà et ça s'appelle MacOS X...
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !

Dans l'article <ee43la$236s$2@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> disait :

Marc Espie <espie@lain.home> wrote:
pas, mais qui est plus proche du tien, est qu'un système de paquets ne peut
fonctionner correctement qu'à partir de paquets binaires. C'est ce que fait
Debian, et ça marche. J'en ai encore eu l'expérience récemment, il n'y a pas
de doute que ça marche vite et bien.

Oui mais non. Outre le vieux problème récurrent de la manière dont sont gérées
les packages Debian (liés aux releases, etc. ce qui est absurde), les
distributions binaires souffrent d'un problème tout bête : la manière dont
sont exprimées les dépendances.

J'explique : dans Debian & FreeBSD (et sans doute NetBSD mais je n'ai pas
vraiment étudié pkgsrc), un paquet binaire dépend d'un ensemble
potentiellement grand d'autres paquets binaires. Lesquelles dépendances sont
exprimées via... un numéro de version de paquet.

Et bien ça ne fonctionne pas comme ça (ne devrait pas devrais-je dire).

Actuellement ça donne l'impression de fonctionner parce que les gens n'ont
plus vraiment de problème de bande passante avec les hauts débits, etc. et ça
ne leut fait ni chaud ni froid de télécharger N versions de la glibc et de
ld.so, de toutes façons, ils ne le voit pas (qui surveille exactement ce qui
est téléchargé en automatique).

Mais c'est complètement idiot. Les dépendances sur les bibliothèques partagées
ne devraient être exprimées qu'en terme de version d'ABI (Application Binary
Interface), rien d'autre. Si l'ABI n'a pas changée (et entre la glibc 2.1.3 et
la 2.1.7 et la 2.1.9 elle ne devrait pas changer)[1], alors le paquet
correspondant n'a pas à être mis à jour.

Ce n'est pas le cas. FreeBSD n'a pas le problème de la libc comme Linux parce
le numéro majeur ne change que dans une version majeure elle aussi mais il
existe pour tous les autres paquets.

FreeBSD au moins travaille à ce sujet mais rien n'est fait. On a déjà de la
gestion de version des symboles des bibliothèques, c'est déjà ça.

L'utilisation de portupgrade/portinstall et de la recompilation systématique
n'a pas ce problème puisque dans les ports, les dépendances vont être
exprimées sur libfoo.so.3 et non pas sur le port libfoo 2.1 ou 2.2.

Voilà pourquoi je me contente d'upgrader ma machine quand il y a des releases,
et purement avec des paquets binaires, si possible. Les outils qui existent
pour faire ça sous FreeBSD soit ne marchent pas, soit sont d'une lenteur
démoniaque. Je voudrais un outil qui regarde ce qu'il y a sur la machine, ce
qu'il y a dans le dépôt FreeBSD, me propose d'upgrader ce qui est possible, de
compiler ce qui ne l'est pas, de faire venir tout ce dont il y a besoin
*avant de commencer quoi que ce soit*. Je ne veux pas que cette phase prenne 3
heures. Apt-get fait exactement ça en quelques secondes pour analyser la

portversion -l '<' suivi de
portupgrade -P (je favorise les paquets binaires)

-----
[1] il est connu que le mainteneur de la glibc se tape de ce genre de notion
et il y a eu moulte changement d'API/ABI depuis que glibc.so.6 existe sans que
le numéro majeur ne change, autre connerie.

--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !

Le Mon, 11 Sep 2006 16:58:27 +0200, didier gaumet a écrit :

[...]

je vais tester l'histoire du ssid non-caché avec NetBSD 3.0.
[...]

marche pô non plus :-(
En passant, je corrige ce que j'ai dit plus tôt, l'intitulé exact que
j'ai dans le ifconfig n'est pas "no carrier" mais "no network"

Ollivier Robert <roberto@removethis.eu.org> wrote:

Oui mais non. Outre le vieux problème récurrent de la manière dont sont gérées
les packages Debian (liés aux releases, etc. ce qui est absurde), les
distributions binaires souffrent d'un problème tout bête : la manière dont
sont exprimées les dépendances.

Les paquets Debian ne sont pas liés aux releases, ce que tu dis est vrai pour
la version Stable. Dans Unstable et Testing il y a justement des paquets qui
arrivent constamment par le haut, sont testés aussi bien pour leur
fonctionnement que pour leur compatibilité avec le reste, et s'ils résistent
tombent dans la catégorie inférieure (ou supérieure comme tu veux). Donc la
personne qui utilise Unstable ou Testing va se trouver dans la même situation
que la personne qui utilise FreeBSD, avec des paquets en flux permanent, et en
particulier un risque d'avoir un système qui ne marche pas.

J'explique : dans Debian & FreeBSD (et sans doute NetBSD mais je n'ai pas
vraiment étudié pkgsrc), un paquet binaire dépend d'un ensemble
potentiellement grand d'autres paquets binaires. Lesquelles dépendances sont
exprimées via... un numéro de version de paquet.

Oui, et si tu regardes comment les dépendances sont exprimées dans Debian, tu
verras qu'il y a des opérateurs relationnels, qui font que ce que tu dis n'a
aucune raison de se produire. Tu as des exemples dans mon papier, j'en cite
un:
Package: libatk1.0-0
Priority: optional
Section: libs
Installed-Size: 188
Maintainer: Akira TAGOH <tagoh@debian.org>
Architecture: i386
Source: atk1.0
Version: 1.11.4-0ubuntu1
Depends: libc6 (>= 2.3.4-1), libglib2.0-0 (>= 2.9.3)

Par conséquent, à supposer que le mainteneur du paquet atk ne se soit pas
bourré dans ses mentions, s'il sait que le paquet 2.3.4-1 contient l'ABI
adéquate, mais pas les versions antérieures, ceci produit exactement l'effet
que tu veux. J'ai cru comprendre que le pkgsrc de NetBSD avait le même genre
de choses.

Et bien ça ne fonctionne pas comme ça (ne devrait pas devrais-je dire).

Actuellement ça donne l'impression de fonctionner parce que les gens n'ont
plus vraiment de problème de bande passante avec les hauts débits, etc. et ça
ne leut fait ni chaud ni froid de télécharger N versions de la glibc et de
ld.so, de toutes façons, ils ne le voit pas (qui surveille exactement ce qui
est téléchargé en automatique).

Non actuellement ça fonctionne, l'autre jour j'ai upgradé mon Ubuntu, de
l'ordre de 130 paquets, dont le serveur X, pas mal de paquets de KDE et de
Gnome, tout ça en travaillant sous X, et ça a pris 15 minutes. Il y a quelque
temps j'ai fait un portupgrade simplement de KDE et de ses dépendances, avec
des paquets binaires présents en local, et ça a pris 4 ou 5 *heures*. Comme
disent les anglais, la preuve est dans le pudding.

Voilà pourquoi je me contente d'upgrader ma machine quand il y a des releases,
et purement avec des paquets binaires, si possible. Les outils qui existent
pour faire ça sous FreeBSD soit ne marchent pas, soit sont d'une lenteur
démoniaque. Je voudrais un outil qui regarde ce qu'il y a sur la machine, ce
qu'il y a dans le dépôt FreeBSD, me propose d'upgrader ce qui est possible, de
compiler ce qui ne l'est pas, de faire venir tout ce dont il y a besoin
*avant de commencer quoi que ce soit*. Je ne veux pas que cette phase prenne 3
heures. Apt-get fait exactement ça en quelques secondes pour analyser la

portversion -l '<' suivi de
portupgrade -P (je favorise les paquets binaires)

Ta solution ne satisfait à aucun des critères que je mentionne au dessus, elle
est d'une lenteur démoniaque, et elle n'offre aucune garantie de succés. Je
veux voir *tous* les paquets nécessaires à l'upgrade sans exception présents
sur la machine avant de commencer à désinstaller ou upgrader quoi que ce soit,
sinon j'ai une chance sur deux de me retrouver coincé au milieu. Je n'arrive
toujours pas à voir comment ces garanties peuvent être apportées par autre
chose que des paquets binaires complets.

Pour dire des choses plus spécifiques à portupgrade, il n'est pas rare que
l'option -P ne soit pas obéie, même quand il a le paquet binaire sous le nez,
et même avec l'option -PP. Ce qui rend le fonctionnement non déterministe.



--

Michel TALON

In article <ee5pr9$anj$1@yquem.eurocontrol.fr>,
Ollivier Robert <roberto@REMOVETHIS.eu.org> wrote:

Dans l'article <ee43la$236s$2@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> disait :

Marc Espie <espie@lain.home> wrote:
pas, mais qui est plus proche du tien, est qu'un système de paquets ne peut
fonctionner correctement qu'à partir de paquets binaires. C'est ce que fait
Debian, et ça marche. J'en ai encore eu l'expérience récemment, il n'y a pas
de doute que ça marche vite et bien.

Oui mais non. Outre le vieux problème récurrent de la manière dont sont gérées
les packages Debian (liés aux releases, etc. ce qui est absurde), les
distributions binaires souffrent d'un problème tout bête : la manière dont
sont exprimées les dépendances.

J'explique : dans Debian & FreeBSD (et sans doute NetBSD mais je n'ai pas
vraiment étudié pkgsrc), un paquet binaire dépend d'un ensemble
potentiellement grand d'autres paquets binaires. Lesquelles dépendances sont
exprimées via... un numéro de version de paquet.

OpenBSD est encore un cas de figure completement distinct.

Precisement, on a entierement resolu ce probleme. Il y a des dependances
`logiques', typiquement, tel paquetage depend de tel autre paquetage, avec
au moins telle version, et des dependances `physiques' qui sont evaluees
lors de la creation des packages.

Le systeme de ports contient toutes les infos necessaires au niveau des
bibliotheques partagees: toute bibliotheque partagee est enregistree aupres
du systeme dans le paquetage (marqueur @lib).
Tout paquetage qui depend d'une bibliotheque partagee est annote de facon
similaire: il y a une variable WANTLIB qui contient la liste des noms de
bibliotheques partagees, et lors de pkg_create, cette dependance est
`figee' en la version de bibliotheque partagee presente sur le systeme.

On a garde les nommages de bibliotheques partagees a.out, et cela donne
quelque chose du genre.

- on compile le paquetage jpeg, qui contient a l'arrivee
@lib libjpeg.so.6.0

- si on compile un paquetage qui depend de jpeg (WANTLIB=jpeg), on se
retrouve en general avec deux lignes:
@depend graphics/jpeg:jpeg-*:jpeg-1.6
@wantlib jpeg.6.0

La premiere ligne indique qu'on depend du paquetage jpeg, qu'on s'accommodera
a priori de n'importe quelle version, et qu'on a ete compile avec explicitement
la version 1.6 (a but de mise a jour).

La deuxieme ligne indique que de toutes facons, ca ne marchera pas sans la
libjpeg.so.6.*

La resolution de dependances est donc double: lors de l'installation, on
verifie les dependances logiques, ET on traverse tout l'arbre de dependances
afin de verifier qu'on a bien les bibliotheques partagees necessaires.

Lors des mises-a-jour, on garde les vieilles bibliotheques qui sont encore
necessaires pour de nouveaux packages. On utilise les infos de type
dependance/no de bibliotheque partagee pour ecrire une `signature' d'un
package, de facon a savoir quand mettre a jour (un paquetage est considere
plus recent s'il differe en termes de signatures): ca permet de s'assurer
que des packages qui ont ete recompiles et dependent d'une nouvelle version
de bibliotheque partagee seront mis-a-jour, ce qui permet a terme de gicler
les vieilles versions.

L'arbre de dependances est garde correct par quelques moulinettes qui
verifient que les annotations de type WANTLIB sont bien presentes... Mais
il faut voir qu'il n'y a pas de mise-a-jour necessaire lorsqu'on change
une dependance, vu que les numeros de version sont calculees au vol par
pkg_create. Il y a juste quelques mise-a-jour penibles, comme gnome qui
s'est mis a integrer gtk/cairo recemment, ou il fallu rajouter plein de
WANTLIB un peu partout...

Cote gestion des numeros de version, on a `pris le controle', a savoir
que tout port contenant des bibliotheques partagees definit les numeros
de version de celles-ci dans une variable SHARED_LIBS. Divers bouts du
systeme (libtool en tete) prennent en compte cette variable. Ca permet
de changer le numero de version lorsque les maintaineurs upstream oublient.
Ca permet egalement d'eviter les `flag-day' sur des gros changements d'ABI,
style grosse modif C++.

(ca nous permet egalement d'ecrire proprement les dependances par rapport
au systeme de base, qui lui n'est pas constitue de packages, mais qui
contient des bibliotheques partagees avec des numeros de version).

Tout ceci, c'est du gros boulot. Le systeme de gestion de packages d'OpenBSD
est entierement reecrit par rapport a celui de Net et Free.
On a une infrastructure perl, basee sur quelques modules, qui permet
d'assurer que pkg_create, pkg_add, mais surtout tous les scripts de
verification (conflicts, dependances, changement de numero de version au
bon moment) utilisent le meme code et les memes algorithmes.

Le travail initial d'annotation des dependances a ete pharaonique. La prise
de controle des numeros de version aussi. Mais tout notre arbre est
maintenant coherent a ce niveau. Et on a des mises-a-jour binaires qui
fonctionnent dans plus de 99% des cas... les cas restants sont des trucs
vraiment bizarres, comme des inversions de dependance. Et ils seront
pris en compte sous tres peu.

Ah, on a aussi du code de prise en jeu d'options (flavors) qui fonctionne.


Va voir n'importe quelle mailing-list consacree a OpenBSD. En pratique, les
gens sont presque tous passes de compilation a la main de ports a
l'utilisation de packages binaires. La 4.0 sera la deuxieme release
avec pkg_add -u (upgrade) fonctionnel.

Le seul gros probleme qui reste a gerer, c'est celui de la distribution:
les miroirs ftp ne sont pas tous mis a jour de facon correcte, et il faudrait
des mecanismes plus solides pour prendre en compte plusieurs miroirs de
facon simultanee.

On a aussi en projet de rendre plus transparent encore l'interaction
ports/packages: on peut deja telecharger automatiquement des packages pour
satisfaire des dependances avant de les compiler. On devrait bientot pouvoir
faire l'inverse (donner une entree de type SRC:/usr/ports dans PKG_PATH
pour indiquer que pkg_add, en desespoir de cause, peut tout compiler a
partir des sources).

Bref, le but avoue, c'est d'enlever encore des trucs pour que ca soit
plus simple pour l'utilisateur. A terme, sous peu, on pourra faire
pkg_add -u, et revenir une demie-heure apres et avoir la machine mise-a-jour
de facon correcte...

Ollivier Robert <roberto@REMOVETHIS.eu.org> wrote:

Hélàs je penche pour cette solution. Il y aurait un gros travail de
packaging et de pre-configuration des applis de bureautique pour qu'un
BSD soit lambda-friendly.
Ca existe déjà et ça s'appelle MacOS X...

On peut avoir tout de même des motivations pour tenter d'occuper ce
créneau...

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org