Nouvelles pistes pour une distribution de TeX

Cahiers

enberg

GUT GUT GUT

m NOUVELLES PISTES POUR UNE DISTRIBUTION DE TEX

P Benjamin Bayart

Cahiers GUTenberg, n  35-36 (2000), p. 121-132.

<http://cahiers.gutenberg.eu.org/fitem?id=CG_2000___35-36_121_0>

© Association GUTenberg, 2000, tous droits réservés.

L’accès aux articles des Cahiers GUTenberg (http://cahiers.gutenberg.eu.org/),

implique l’accord avec les conditions générales

d’utilisation (http://cahiers.gutenberg.eu.org/legal.html).

Toute utilisation commerciale ou impression systématique

est constitutive d’une infraction pénale. Toute copie ou impression

de ce fichier doit contenir la présente mention de copyright.

Nouvelles pistes pour une distribution

de T

E X

BenjaminBayart

Résumé. Onexposerasommairement laproblématique danslaquelleest apparue

l'idée d'unenouvelledistributionde T

E

X. Unediscussion nettement postérieure, et

partantdeproblèmesdiérents,pourladénitiond'unTPM 1

aamenérapidementà

desconclusions extrêmementsimilaires.LesprincipesdebasedeFDNT

E

Xtelsqu'ils

ontétéimaginésaudébut,puismodiéslorsdesdiscussionsàproposdeTPM,seront

exposésetexpliquésendétails.

1. The name of the game

Poursacrieràlatradition:pourquoicenomlà?SimplementparcequeFDN

(French Data Network,association loi1901,fournisseur d'accèset de services

Internet) héberge les serveurs pour le projet (CVS, Web, Ftp, etc) et qu'à

l'origineduprojetils'agissaitdeproduireunedistributioninstallablepartous

lesmembresdubureaudeladiteassociation.

Au chapitre du vocabulaire, dans cet article, on entendra par package une

extensiondeL A

T

E X2

"

tellequ'attendueparlacommande\usepackage;etpar

module unélémentlogicielunitaireinstallable,parexempleunchier.rpm,ou

.deboudetoutautreformatsimilaire.

2. Pourquoi une distribution?

L'apparitiondedistributions deT

E

X cohérentes, simplesàinstaller,et dispo-

nibles sur une grande variété de systèmes, tient une place de choix dans les

améliorationsrécentesconnuesparlessystèmesbaséssurT

E X.

Bienentendu, danslesdistributionsquel'on rencontredenosjours,teT

E X et

fpT

E

X(satranspositiondanslemondeWindows)sontl'aboutissementdecette

évolution.

1. TXPackageManager.

Un problèmerencontrélorsdetravauxrelativementrécentsàmisaujourune

défaillance dusystème de distribution actuel : le système en cours d'écriture

exigeaituneinstallationparticulièredeT

E

X,certesbaséesurteT

E

X,maiscom-

prenantégalementnombred'extensionsquin'yavaientpasencoreétéintégrées.

Commentreproduirerapidementetsimplementuneinstallationdecetype,en

latenantàjoursi possible?

Fairecroîtreladistribution debaseen contribuantàsondéveloppementn'est

pasunesolutiontoutàfaitsatisfaisante:lerésultatdeplusieurscollaborations

decetypeserait,àterme,unedistributiond'unetaillebientropimposante,et

qui, pourunusage donné,comporteraitune majoritédecomposants inutiles.

De surcroît,desproblèmesde cohérenceet demaintenanceseposeraientpro-

bablement : comment maintenir tel composant intégré par une personne qui

depuisnes'intéresseplusauprojet?

De là naquit l'idée d'une distribution plus souple, plusmodulaire, ayantune

bonnegestiondesdépendancesinternes.C'étaitlandel'été 1998.

3. Les objectifs visés

Des 18mois detravauxsurla distribution,desdéveloppementsdes diérents

prototypes,etdesnombreusesdiscussionsquionteulieuautour,danslemonde

T

E

Xet avecdes administrateurssystèmes, ilest ressortiplusieursidéesfortes

qui sontlefondementduprojetactuel.

Cettedistributiondoitdoncsatisfaireauxobjectifssuivants,parfoiscontradic-

toires,qui serontexpliquésplusavant:

modulaire;

lapluscomplètepossible;

minimaleunefoisinstallée;

portablesurplusieurssystèmes,avecunordredepréférence;

dédiéeausystèmesurlequelonl'installe;

documentée.

3.1. Une distribution modulaire

C'est làlaclefdevoûtedusystème:unedistributiondeT

E

Xmodernesedoit

d'être modulaire,bien plusquece qui fututiliséjusqu'àprésent.Pourquoice

choix,et pourquoile pousser presqueà l'extrême? Pourrépondre àces deux

exemplesclassiques.

Le premier exempleest uncas simple.Qui utilise, ne serait-ce qu'occasionel-

lement patgen?Qui ace programme installé parsa distribution de T X? À

E

lapremièrequestion,une inme minoritéaura répondu utiliser celogiciel 2

, à

la seconde (vériez sur votre teT

E

X habituelle), une immense majorité aura

répondudisposerdulogiciel.Unemajoritéd'utilisateursadoncinstalléunlo-

gicielinutile. Ils'agit làd'un casprécis,etpeualarmantétantdonnélaplace

priseparce logiciel,maisil estloind'êtreisolé.

Lesecondexempleest uncas moinssimple,maisquiseraamenéàdevenirde

plusenplusfréquent.Quelqu'unqui auraitbesoind'utiliser pourcomposer

enUnicodeetbénécierdesextensionsapportéesparcemoteur,etégalement

d'utiliser,devraitpouvoirnepasinstallerT

E

X . Bienquecelapuissesembler

paradoxalpour une distributionde T

E

X. Les versions alternativesau moteur

T

E

Xclassiqueétantdeplusenplusnombreuses,etdeplusenplusutilisées,ce

typedechoixvasemultiplier.

Laseuleréponsepossibleàcesdeuxproblèmesestd'avoirunedistributionqui

neprésupposequetrèspeudechosevoire, sic'étaitfaisable,rien.

Deplus, certainessegmentationsqui peuventsemblerde primeabordcontre-

nature ont été faites. Par exemple, le chier modes.mf a été isolé dans un

module pourpouvoirêtremis àjour très simplement,et àmoindre coût,par

exemplepouradapteruneinstallationàune nouvelleimprimante.

3.2. Prévoir le maximum de modules

Une telle distribution, étant modulaire à un niveau n (puisqu'ondoit pou-

voirinstallerT

E

Xete-plain,sanspourautantinstallerplain),pourra,etdonc

devra, intégrersansscrupules lemaximumd'extensionsclassiquesou plusin-

habituelles.

En eet, il serait dommageable que l'on puisse installer des extensions pour

le japonais, mais que l'on doive installercertaines extensions mathématiques

extravagantes à lamain. Un desbuts doit donc être de mettre à disposition

del'utilisateur nal unmaximumdefonctionnalités dans lesquelles ilferaun

choix,quitteàrevenirsur sonchoixplustard,quandil aurabesoind'ajouter

oudesupprimerdesfonctionnalités.

3.3. Le minimum de perte à l'installation

Le système d'installationde la distributiondevra installer lestrict minimum

pourmettreen÷uvrelesfonctionnalitésdemandéesparl'utilisateur,and'évi-

terlecascitéplushautdepatgen.

2. Pourlesautres,ceux,innombrables,quines'ensontjamaisservi:patgensertàgénerer

ladescriptiondesmotifsdecésurepourunelanguedonnéedansunformatlisibleparTX.

L'ensemble des modules installés devra donc être la fermeture transitive

desmodulesdemandésparl'utilisateuretdeceuxquileursontnécessairepour

fonctionner.

Pouratteindrecetobjectif,unegestionneetrigoureusedesdépendancesentre

modulesseranécessaire.

Un système idéal devrait même être capable, lorsque l'utilisateur déclare ne

plus avoirbesoind'une desfonctionnalités qu'il avait demandé audépart, de

supprimertouslesmodulesquinesontplusrequis.Untelsystèmen'existepas

encore, et pourrait avoir quelques eetsde bord inattendus et parfoisdésas-

treux:quel'utilisateurdemandeinitialementunmoduleA,quirequiertBqui

n'apasétéspéciquementdemandé,puiss'habitueàutiliserB,puisdemande

ladésinstallation deA qu'iln'utilise plus, siBn'estplusrequis parpersonne

il serasupprimé, etladisparitiondeBrisqued'êtredéroutante.

3.4. Ne pas perdre la portabilité actuelle

LaportabilitédesdistributionscourantesdeT

E

Xestengrandepartieliéeàla

portabilitédeT

E

Xlui-même,etdesprogrammesquiontétédéveloppésautour.

Ilnefaudraitpasquecette grandequalitédisparaisse.

3.5. Ajustement n au système cible

Cet objectif là ne découle pas directement des problèmes exposés précedem-

ment,maisplutôtdelagrandemodularitéàlaquelleonarrive.Pourgérertous

ces modules, leursdépendances, leurinstallation, leur miseàjour, leur con-

guration, etc, il faudra unsystème qui ne serani simpleàécrire, ni simpleà

manipuler.

L'utilisateurnaldeladistributionaura,apriori,étéamenéàutiliserdesoutils

similaires pourinstallersonsystème d'exploitation,et ilserait doncjudicieux

que les modules de la distribution nales soient manipulables par les mêmes

outils.Celapermetdetransformercequiauraitétéuneconnaissancespécique

àT

E

Xenuneconnaissancespéciqueausystèmed'exploitationutilisé.

Toutefois, pour les systèmes ne prévoyant pas ce type d'outils, ou pour les

personnes qui ne souhaitent ou ne peuvent pas les utiliser, il sera nécessaire

deprévoirunedistribution baséesurdesoutilsplustraditionnels commeceux

d'archivage.

Ainsi,lebutestd'obtenir,parexemple,unevariantedeladistributionmanipu-

lable avec swtoolspourlesutilisateursdeHP-UX, unevariante manipulable

E

Description

Fichier.spec Makeles ArbreDebian

RPM portBSD DEB

rpm make dpkg

Fig.1Représentationduprocessusdegénérationdesdiérentesvariantesde

FDNT

E

Xdepuisunedescriptionuniquedechaquemodule.

Une conséquence directe, pour garantir la cohérence de l'ensemble entre les

diérentes variantes,est qu'ilestindispensabled'automatiseraumaximumla

créationdecesvariantes.

3.6. Documentation

Si chaque module doit, comme c'est devenu la tradition,être diusé avec sa

documentation, il sera nécessaire que la distribution elle-même, ainsi que ses

outils propress'il y en a, soit documentée comme il est de coutumedans les

projetsayanttraitàT

E X.

4. Représentation de l'information

Obtenirautomatiquementtouteslesvariantesdechaquemodulesupposequ'il

existeuneuniquedescription,dansunlangagedonné,dumodule enquestion,

et qu'un utilitaire viendra exprimer cette information dans un dialecte plus

aisémentcompréhensiblepourlesoutilsdemanipulationdelavariantevoulue.

Ladescriptiondelamajoritédes modules peutserésumeràtrèspeud'infor-

mations:

une descriptionsipossiblecomplète(auteur, date,version,etc);

une description des quelques tâches simples à accomplir pour produire le

moduleet

une listedeschierscontenusdanslemodule.

Ce langage serait utilisé comme indiqué au diagrammede la gure 1.L'idée

ressembleunpeuàcequi estutilisé actuellementparcertainsML, ouqui fut

utiliséparKnuthpourweb:unseulsource,qui,selonletraitementqu'onlui

faitsubir,produiraplusieursrésultatsradicalementdiérents.Dansnotrecas,

selonleformatdesortieretenu,àpartirdeladescriptiond'unmodule,ondoit

être capabledeproduire unedescriptionqui convienneàrpm(doncunchier

.spec),ouaumécanismedeports deBSD (unesériedechiersarchitecturés

autour d'unMakefile),ou...

Dans le même esprit, produire un descriptif de la distribution, à mettre en

ligne, ousurpapier,ou enPDF, ouencorecontribueraucataloguequi existe

déjà, peutserésumeràajouterunformatdesortieausystème.

C'est ce format de description des modules qui fut radicalement changé par

l'approchedeTPM.Ilesteneetapparuquelelangagerapidementimprovisé

quiétaitutilisédanslespremiersdéveloppementsn'étaitpas,deloin,susant.

De l'avis général, XML semblait le meilleur choix possible. À l'heure où cet

article est écrit, la DTD exacte n'est pas arrêtée, on décrira donc la nature

et la qualité des informations qui devront être représentées plutôt que leur

formalisme exact.

Schématiquement, la descriptiond'un module peut se décomposer en quatre

parties, ou plusexactement, trois parties, et des informations permettant de

combinerletout.

4.1. Préliminaires

Ils'agitlàdetouteslesinformationsclassiquesd'identicationdumodule:son

nom,lenomdel'auteur,ladatededernièremodication,lenumérodeversion,

desdescriptionsvariées(plus oumoins longues,enplusieurslangues,etc).

Toutes ces informations sont sans particularités intéressantes par rapport à

une distributionde n'importe quel autre logiciel, onpourra, par exemple, se

basersurlecatalogueexistantpourlestrouver,dansunpremiertemps,avant

d'envisagerdeproduirele-ditcatalogueàpartirdesinformations.

Bienque cesinformations nécessitentune granderigueuret soientfondamen-

E

4.2. Dépendances et liens

Laproblématique desdépendances entre modules (quel module requiert quel

autre pour fonctionnerconvenablement)est beaucoup plus complexe. Lemo-

dèleretenu devrait être capable d'exprimer deschoses assez nes.Voyonsles

casles plusinhabituels, c'est-à-direceuxqui sortentd'unesimple relationde

dépendance tellequetabularxrequiertarray.

Les fonctionalités pour reprendre une terminologie déjà utilisée par

d'autresdistributionsd'autreslogicielsquipermettentdedire,parexemple,

qu'unmodulerequiertunT

E

XetnonpasleT

E

X.Eneet,lesfontesEContpeu

desenssansunmoteurT

E

Xpourréaliserlamiseenpage,mais, qu'ils'agisse

deT

E

X, d'oud'"-T

E

X ,peuimporte.

Cettenotiondebase devracertainementêtreranée,parexemplepourindi-

querquel'onabesoin,pourtirerpartidesfontesPostScriptd'unpilotecapable

d'utiliser detelles fontes (eneet, dvipsn'estpasnécessairementleseul), et

passimplementd'unpilotequelconque.

De nombreux formats de descriptionde modules d'autres distributions four-

nissent un mécanisme similaire, sa réalisation et son formalisme, quel qu'ils

soientdanslaDTD nalementretenueserontfonctionnelset ecaces.

Certainsproblèmespourraientcependantrestersanssolutionaveclesapproches

classiques, parexemple: le packagefrenchabesoinpour fonctionnerconve-

nablement,soitdefontes accentuées,soitd'unmoteurMlT

E

X .Deuxfonction-

nalités remplaçables l'une par l'autre, dans cet usage précis, mais trop

diérentespourêtreconsidéréesidentiques.

Dépendancesstrictesetdépendanceslarges sontnécessairespourl'im-

mense majorité des cas, si l'on souhaite permettre une sélection précise de

ce qui est installésur unsytème. L'exemple classique est unpackagedontle

mode d'emploi utiliseunefonte inhabituelle quin'estaucunementrequisepar

lepackagelui-même.Pourfonctionnerdemanièreoptimale,lemoduledevrait

disposerdelafonte,pourquel'onpuisselirelemoded'emploidansdebonnes

conditions,mais c'est unluxe qui est bien inutilepourquelqu'un qui dispose

déjàdecemoded'emploisousuneautreformeoun'enasimplementpasbesoin.

Demême, le programmede génération automatiquedefontes est prévu pour

manipuler des formats très diérents, et devrait donc, en toute rigueur, dé-

pendrede touslesoutils de génération detous cesformats. Mais il n'estpas

utilede produire l'imaged'unefonte PostScriptsur unsystème ouseulesdes

fontes

METAFONT

Dansce cadrelà,unniveaudedépendance entre0et unmaximumM donné

pendants,Mquandilestinenvisageabled'utiliserl'unsansl'autre,et,entreles

deux,uncertainnombredeseuilscodiés:nécessaireaumoded'emploi,néces-

saire pour des modes d'utilisation peu fréquents,nécessaire pour l'utilisation

habituelle,etc.

Dépendances vis-à-vis du système cible , par exemple, la nécessité

d'avoiraaire àune versiondonnée d'un système totalement hors de la dis-

tribution. Lesexemplessimplespouvantêtredesbibliothèques X11(ouX10),

un préprocesseur,unoutil de développement commemake,etc. Si ces dépen-

dances sont simples à exprimer dans le contexte d'une distribution pour un

système, ellesdeviennentbeaucouppluscomplexesàformaliser.

Deux mécanismescomplémentaires permettant de résoudre ce problèmesont

envisagés. L'un basé sur des exceptions : le module dépend de A dans le

cas général,mais de Aet B pour telle variante . L'autrebasé surdes dépen-

dances purement formelles, quine serontévaluées qu'aumoment deproduire

la variante de ladistribution correspondantà unsystème donné : requiert

ladisponibilitésdesthreadsPOSIX quiseraultérieurementévaluéenre-

quiertuneversiondusystèmepostèrieureà42.1ourequiertlabibliothèque

xxx.

Liens entre deux modules autre que dedépendance.Parexemplein-

diquer larelationentretangleet weave,qui nesontpasstrictosensu dépen-

dantsl'undel'autre.Ouencorelarelationqu'ilpeutyavoirentredeuxfontes

qui sontprévuespourêtreutiliséesensemble, commeparexempledeuxfontes

PostScriptdonnées,mêmesicelanepeutpasêtrevucommeunecontrainte.

4.3. Actions

Le troisièmetyped'informationnécessaireàladescriptiond'un module estla

série d'actions qui doivent être entreprises pour mener à bien les diérentes

étapesdesavie(installation,suppression, remplacementparuneversionplus

récente,etc).

De même,lesdirectivesdecompilationdevrontêtre indiquéespuisque lesdif-

férentesvariantesdeladistribution devrontêtreproduitesautomatiquement.

Cesdeuxcas,quipeuventsemblersimples,nelesontpas.Eneet,si,pourune

variante donnéede la distribution,ces informationssont leplus souventtrès

simplesàécrire,ellesdeviennentbeaucouppluscomplexesdanslecadred'une

descriptiongénéraledemodule.Unedesdiérencesfondamentalesconstatées,

mêmeentredeuxvariantessurdessystèmesUnix,estl'approchechoisieparle

système:certainsutiliserontdesscriptsshell,etd'autresdesMakele,induisant

E

Lapremière approcheretenue, qui semble laplus généraliste, étaitde choisir

unlangagepuissantetexpressif,et d'apprendre,aufuretàmesure,àtraduire

les fonctionnalités utilisées dans les autres languages. Par exemple, traduire

leshellde rpmenMakelepourles ports BSD.Cetteapproche,doubléed'un

mécanismed'exceptionpourlesfonctionnalitéstropcomplexesàtraduire,avait

l'avantaged'êtreunmodèleouvertetdoncsouple,maisledéfautdenepasêtre

stable,puisquelelangageévolue,ainsiquelesoutilsdetraductionautomatique,

àmesurequeladistributionsecomplète etquelescasdiciles apparaissent.

Unesecondeapprocheestcelle d'unlangageconcisetminimalistepermettant

dedécrire lessituations les plusfréquentes,et unmécanisme d'exceptionpar

module pour ceux qui demandent trop de travail. Par exemple, compiler la

documentation d'un packageest une chose simple à décrire dans un langage

dehautniveau,lesseulesvariablesdansleprocessusétantlenombredecom-

pilationsrequises,laprésence ounon desdiversindex oude labibliographie,

et leséventuelsannexes classiques commedes graphiques

METAPOST

l'avantagede menerà unsystème fermé, donc plus aisémentdiusable, mais

quisouriradoncdegraveslacunesdanssespremièresversions.

4.4. Congurationet administration

La conguration (et/ou administration) de la distribution est un problème

multiplequi, s'iln'estdéjàpasévidentàtraitersurlesdistributionsactuelles,

deviendrabien piredansunedistributionmodulaire.

La premièreévidence est que, si on souhaite que lesystème soit utilisable, il

fautquelesoutilsdecongurationsoienteux-mêmemodulaires,etquechaque

module en ayant besoin contienne la partie de l'outil de conguration qui le

concerne. En eet, on ne peut pas envisager un outil qui contiendrait déjà

tout le nécessaire pour congurer tous les modules, et déciderait des actions

àentreprendre enfonctiondece quiest installé:l'outil reétteraialorsl'état

de la distribution à unmoment de son évolution, et non pas ce qui est réel-

lementinstallésurlamachine.D'autrepart,sichaquemodulefournissaitson

propreoutilde conguration,l'ensembleseraittrès rapidementinutilisable, la

cohérencedesoutilsentreeuxn'étantpasassurée.

Il conviendra donc, avant que la distribution puisse être considérée comme

utilisableparlegrandpublic,qu'unteloutilsoitdéveloppé.Unautreintérêtde

cetteapprocheétantque,sionaunoutilcentralassezgénérique,etdespièces

ajoutéesparchacundesmodulesinstallé,alors,l'outilcentralpeutêtreadapté

précisément ausystème sur lequelil serautilisé, du momentqu'il respectele

Toutefois,certainscas simpleset classiques decongurationseront modélisés

dansunlangagerestreint.Parexemple,l'ajoutd'unformatpourcertainsmo-

teursT

E

X estuneopérationquirestetoujoursplusoumoinslamêmeetpeut

doncêtredécritedemanièregénérique.

4.5. Imbrications

Une dernièreformed'informationdevraêtre contenue dansladescriptiondes

modules,sanspourautantêtre,apriori,rattachéeàunmoduledonné:lafaçon

dontceux-cipeuventêtreimbriqués.

Eneet,sionsouhaiteêtreenmesuredefairedeT

E

X,

METAFONT

trois modules autonomes,il faudra, àpartirdusource habituelde l'ensemble

web2cêtreenmesure deproduireplusieursmodulesbinairesdirectementins-

tallables.

Les modèlesdesoutils deconstructiondedistributions quel'on rencontre ac-

tuellementpossèdentpresquetouslanotionde sourceuniquequi produit

plusieursmodules.Maiscettenotion,pourpuissantequ'ellesoit,n'estpassuf-

santedanslecasprécisd'unedistribution deT

E X.

Lecastypequiposeproblèmedanscemodèleestceluid'.Eneet,celogiciel,

techniquement,estune modicationdeT

E

X. Ilfautdonc,sionveutproduire

uneversionexécutabled'produireégalementuneversionbinairedeT

E X ,ou,

plus exactement, c'est lecheminement le plusnaturel. Ainsi, il faut, àpartir

de deuxsources (web2cpourtout lesoutilsT

E

Xhabituels,et omegapour

lesextensions)produireuntrèsgrandnombredemodules:tousceuxcontenus

dansweb2c,àsavoirunevingtaine,plustousceuxpour.Lemêmeproblème

seposerapouroxdvi 3

quiest distribuécommeunemodicationdexdvi.

À ce jour, aucun modèle able et générique n'a été choisi pour indiquer que

n sourcesproduisentmmodules. Lemodèleleplussatisfaisantseraitceluide

RedHat,pourrpm,maisilrestetropsimpliste pourcertainscas.

5. État d'avancement

LeprojetFDNT

E

Xest encoreenpleineévolutionetne pourrapasêtreconsi-

dérécommeutilisablelargementavantdelongsmois.Cependant,leprojetest

susamentavancépourquedesutilisateursavertispuissentfairedestests,et

l'utiliser demanièrequotidienne.

E

5.1. Le prototype

Avantd'arrêterunedénitionprécisedecequedevaitrecouvrirleprojet,etde

cequ'ildevaitêtreàterme,unprototypecomplet,contenantàpeuprèstoutce

qu'onest endroitd'attendre d'unebonnedistribution deT

E

X aétéréalisé.Il

n'existequedeuxvariantesàcejour:Linux(rpmsurprocesseursIntel,Sparc,

etPowerPC),etlesportsFreeBSD3.0pourIntel.

Ceprototypeestgédepuisjuillet1999etn'évoluequasimentplus.

5.2. Le langage de description

Lelangagededescriptiondemodules ored'oreset déjà,àl'heure actuellela

majoritédesfonctionalitésattendues,audétailprêtqu'iln'estpasencorebasé

sur XML, i.e. leschamps, leursens et leurstructure sont valideset exploités

parplusd'une centaine demodules, mais n'ontpas encorelebonformalisme

derédaction.

Lesfonctionnalitéspourlesquellesunemodélisationdesdonnéesn'apasencore

étémiseenplacesont:

modélisationdesdiérentsniveauxdedépendance(stricte,large,etc),peude

modèlesdedistributionsutiliséspardessystèmesd'exploitationspermettent

cettefonctionnalités, aussileformalismen'apasencoreétéarrêté;

modélisation des fonctionnalités avancées (le cas MlT

E

X/fontes EC),

parcequelescontoursréelsdecequidoitêtremodélisablenesontpasclairs,

lenombredemodules ayantbesoindetelles dépendances étantencoretrop

faible;

les dépendances vis-à-vis dusystème ciblene sontpas modélisées mais re-

prises directement dans la variante voulue, simplement parce que ces dé-

pendances sont, pardénition,liées auxsystèmes cibles et donc peu utiles

àmodéliser demanièregénérique, une modélisation générique seramenant

à une simple table de correspondance du type Threads POSIX se dit

libpthread-1pourRPM,;pourlesportsBSD,etc;

lesliens autresqueladépendance;

lelangagedehautniveau modélisantlesactionsn'estpasformalisé;

lacongurationdesmodulesn'estpourlemomentpaspriseencompte;

lesimbricationsnversmsontmodéliséesmaisnesontpasréaliséesdans

touteslesvariantes.

5.3. Les variantes

Les variantes actuellement existantes ou en cours de développement sont

Linux/Debian, portable également sur diérentes architectures; et FreeBSD

sur Intel,leportageversles autresversions libresdeBSD devantêtrefacilité

par lefait qu'OpenBSD, NetBSD et FreeBSD partagentle même système de

ports.

Le choix d'unix libres pour les premières variantes est un choix induit par

le fait, simple,qu'il faut disposer du système cible pourproduire lavariante

correspondante.Lasecondeétapedanslalistedessystèmesciblessera,apriori,

les unix non-libres, qui demanderont des volontaires disposant des systèmes

pourledéveloppement.Ensuiteseronttraitéslessystèmesbaséssurdesc÷urs

detypeUnix(parexempleMacOS-X,NeXTStepet BeOS).

Deplus,unportverslessystèmesMicrosoftestenvisagé,surlemêmeprincipe

quefpT

E

X, sidesdéveloppeurscapablesdeleréalisersouhaitents'enoccuper.

5.4. Échéancier

Bienentendu,surce typedeprojet,fonctionnantessentiellementsurdubéné-

volat,donnerdesdates nepeutêtre qu'indicatif,etne peutconcernerqueles

parties duprojetpourlesquellesdesvolontairessontdéjààlatâche.

Deplus,cetéchéancier,indicatif,estceluiàladatederédactiondecetarticle,

soit deuxmoisavantGUT-2000.

À retenirdonc:

avril 2000 languagededescriptionenXML,premièreDTD.

juin 2000 premièrevarianteenRPM.

août 2000 portsBSDet Debian.

décembre 2000 diusion,danscestroisvariantes,d'unedistribution,sipos-

sibleaumoinséquivalenteàteT

E

X,versiondelaDTDaprioridénitive.