Forum général.général Vers un nouveau modèle de développement

Posté par  .
Étiquettes :
0
9
nov.
2007
Les applications peuvent se diviser en plusieurs catégories.
Nous distinguons :

A = Les applications finales. Exemples :
OOo, firefox, Gimp, apache

B = Les applications dont dépendent celles de A. Exemples :
gtk, libpng, Java, python

C = Les applications dont celles de A peuvent dépendre, mais d'une façon moins forte, ou qui sont relativement importantes pour le système. Exemples :
make, tar, grep

D = Les applications critiques. Exemples :
le noyau, libc, grub, bash, xorg (qui selon les cas peut se retrouver en B)

----------------

À partir de cette analyse nous pouvons faire quelques remarques.

* Dans l'idéal, les applications de A peuvent être mises à jour dès qu'il y a une nouvelle version stable en amont.
La possibilité d'avoir plusieurs branches (exemple apache 2.0.X, apache 1.3.X), est un plus considérable, et permet de laisser une grande partie de la maintenance aux développeurs amont, la distribution se contentant de packager.

* Une nouvelle version d'une application de A peut nécessiter une mise à jour d'une de B. Ce qui peut entraîner des recompilations de A, ou en tout cas de nouveaux tests à effectuer.
Ce sujet sera traité en profondeur dans une prochaine étude (certaines techniques permettent de remédier en parti au problème). On peut déjà conseiller aux intéressés la lecture de [1], [2] et [4].

* Les mises à jour de B et C doivent se faire au cas par cas, et sous certaines conditions.

* Un type d'application peut se retrouver dans plusieurs ensemble à la fois.
Prenons par exemple un gestionnaire de bureau (KDE ou Gnome). Une distribution peut décider, afin de satisfaire l'utilisateur, de choisir KDE comme bureau par défaut, de le placer en C, et tous les autres environnement de bureau en A. L'utilisateur choisira alors s'il veut la stabilité ou les dernières avancées.

* D'une façon général, il est difficile de faire une partition des applications.


Les liens [3] et [5] (surtout [3]), sont en rapport.


[1] http://www.dragonflybsd.org/docs/goals.shtml#packages
[2] http://www.pkgjam.org/
[3] http://www.modeemi.fi/~tuomov/b/archives/2007/03/03/T19_15_2(...)
[4] http://wiki.rpath.com/wiki/Conary
[5] http://beranger.org/index.php?page=diary&2007/10/25/13/2(...)

  • # Zero Install

    Posté par  . Évalué à 2.

    Des lectures intéressantes, mais il eut été bon de faire une petite intro avant de passer directement à un argumentaire dont on ne sait pas où il va mener.

    Je radote, mais ça me fait penser à Zero Install ( http://0install.net ), qui plus ou moins s'occupe de A et B, laissant le système s'occuper de C et D. Ça permet de s'abstraire véritablement du système de base.

  • # pkgsrc a 10 ans

    Posté par  (site web personnel) . Évalué à 2.

    Comme lien, avant pkgjam, j'aurais mis pkgsrc.
    http://www.netbsd.org/docs/pkgsrc/ Hé oui, il est déjà possible d'avoir une distribution qui s'occupe du système (debian, netbsd, macosx...) et d'installer par dessus la couche de paquets logiciels utiles (pkgsrc). Et donc, le "nouveau" modèle de développement a 10 ans.

    Pour ce qui est de la partition, bash est pour moi une application finale. Elle fait aussi partie de C. Les environnements de bureau sont de mon point de vue des sortes de framework, et donc devraient plutôt être en B (distinguer gnome de libgnome ou kde de kdelibs n'a pas grand sens vu leurs corrélations). La distinction que tu fais est en fait entre le système (D), et les build_dependencies que l'on peut désinstaller une fois le programme voulu installé (C), runtime_dependencies (inclus dans B : python, jre) et library_dependencies (inclus dans B : libpng, ...). Cette distinction est faite dans un certain nombre de gestionnaires de paquets (pkgsrc, macports, probablement les autres).

    Et pour les intéressés, http://www.netbsd.org/gallery/10years.html

  • # Gniarf Linux Project

    Posté par  . Évalué à 3.

    C'est vraiment très interessant.

    • [^] # Re: Gniarf Linux Project

      Posté par  (site web personnel) . Évalué à 3.

      j'ai hâte de pouvoir lire la suite sur son blog :D le suspince est intense.

      • [^] # Re: Gniarf Linux Project

        Posté par  . Évalué à 1.

        Je n'ai pas de 'blog'.

        • [^] # Re: Gniarf Linux Project

          Posté par  (site web personnel) . Évalué à 3.

          \o/ ah mais tu peux de nouveau poster des commentaires ? :D

          bon, bin, fais un blog plutôt que de polluer toutes les ML que tu trouves et autres newsgroups :-)

          ah et quand tu reviens sur #gcu n'oublie pas de montrer une copie d'écran d'un OS propre :p

  • # Analyse intéressante mais dépassée ?

    Posté par  . Évalué à 1.

    Cette analyse est intéressante et cohérente (à améliorer en tenant compte des divers commentaires déjà postés).

    Cependant, celle-ci concerne le monde des bons vieux logiciels écrits en C, compilés à la main et installés en dur sur le poste client (je caricature volontairement).

    Vraisemblablement, de nouveaux types d'applications apparaissent (et vont probablement se généraliser), en particulier les applications hébergées, les applications client riche, etc...

    Dans ces derniers cas, l'analyse ci-dessus ne s'applique pas, puisqu'on ne raisonne plus avec une architecture mono-machine, avec couches OS / outils de base / frameworks / applications... (mais avec un type d'architecture que je ne saurais résumer en une phrase ^^)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.