Connexion
Vous n'avez pas encore de compte personnel ? Vous devriez en créer un. Une fois enregistré vous aurez certains avantages, comme pouvoir modifier l'aspect du site, ou poster des commentaires signés...
Support
Activité du Site

Pages vues depuis 06/01/2019 : 12 707 310

  • Nb. de membres 366
  • Nb. d'articles 2 837
  • Nb. de forums 24
  • Nb. de sujets 13
  • Nb. de critiques 0

Top 10  Statistiques

Index du forum »»  Développement »» Développeur débutant sur MorphOS

Développeur débutant sur MorphOS#2209

6Contributeur(s)
BeChrisze_bucheronBeWorldPapiosaurJediTcheko
2 Modérateur(s)
PapiosaurBeWorld
Papiosaur Papiosauricon_post
@BeChris : il existe en effet déjà un gestionnaire de paquet nommé Grunch dispo ici :

https://www.geit.de/eng_grunch.html

Il est très bien MAIS dans son cas :

- certains fichiers db créées par les développeurs contenant les recettes ralentissent fortement le démarrage du logiciel Grunch (difficile de savoir pour quoi)
- les fichiers sources sont sur les sites des développeurs principalement ce qui limite la base de donnée

J'avais demandé à Geit de l'adapter à MorphOS-Storage mais je crois pas qu'il était d'accord dans le principe.

Après on peut refaire un logiciel s'en inspirant.

Ce qui serait bien c'est de partir de la base de données de morphos-storage avec le vrai chemin des fichiers, un fichier MUI qui récupèrerait la base de données qui serait mise à jour tous les soirs par exemple.

Le gestionnaire de paquet pourrait comparer les logiciels installés avec la base de donnée et demandé la mise à jour automatique des logiciels dès qu'il y en aurait de dispo.

Le numéro de version de chaque archive se trouve dans le nom du fichier si cela peut servir, exemple Augustus_3.0.1.lha :-)

Après je pense, le plus dur c'est de faire un scan du système et voir ce qui est déjà installé...

Faudrait détecter les fichiers .info en lien avec un fichier exe et demander le numéro de version...

Si je peux aider, n'hésite pas à me solliciter ;-)
 Message édité par : Papiosaur / 21-05-2021 18:47
BeChris BeChrisicon_post
Bonjour les gars.

@Papiosaur : oui effectivement je viens d'essayer Grunch.
Je sais que les goûts et les couleurs ... mais je ne suis pas forcément fan de l'ergonomie de l'outil.
En plus, comme tu l'indiques, je le trouve très très lent pour télécharger les fichiers de bases de données (pourtant j'ai la fibre).
Ca doit peut-être venir des capacité du Mac Mini mais ça vient sûrement aussi du fait les fichiers de base de données semblent assez volumineux pour certains.
Dommage qu'il n'ai pas passé à les stocker sous forme compressée.
Et puis je persiste et signe : une seule personne semble s'occuper de l'outil est il n'est pas open source.
Du coup tout le monde est obligé de l'utiliser tel qu'il est et si t'es pas content ou que le développeur ne veut pas intégrer tes demandes d'évolutions tu es marron.
C'est pour ça que je crois qu'un outil en open source à sûrement plus de chance de s'en sortir.

Ensuite, comme tu le dis également, je pense qu'un scan du système pour savoir ce qui est installé semble compliqué (vu qu'il n'y pas de chemin d'installation "standard" comme sous Linux par exemple).

@ze_bucheron:
En fait l'outil servirait effectivement:

  • Pour les utilisateur : permettre l'installation/mise à jour/désinstallation de logiciels et de leurs dépendances (c'est déjà ce que fait Grunch si je ne me trompe pas)

  • Pour les développeurs : permettre de spécifier quelles sont les dépendances permettant la compilation d'un logiciel (par exemple indiquer que OpenTTD a besoin des fichiers de développement de la SDL2 en version 2.0.14, que GrimoriumPDF a besoin du compilateur de Hollywood en version 8 + le plugin Hollywood Polybios en version 1.3)
    Grunch ne couvre pas ce besoin (si je ne me trompe toujours pas) si cher aux développeurs d'après moi



Concernant l'écriture des fichiers de recettes, le développeur devrait effectivement écrire son fichier de recette.
Ça peut être quelqu'un d'autre mais il est vrai que le développeur est le mieux placé pour ça.
C'est du boulot en plus mais ça lui facilite la vie sur le moyen/long terme : il indique une seule fois les fichiers de développement dont il a besoin (fichiers !!!!include!!!!s de la SDL2 par exemple) et les commandes à lancer pour construire son logiciel (lancer make par exemple) et ampkg s'occupe du reste.
Ce qui est bien dans cette approche c'est que si un autre développeur veut donner un coup de main, il n'a pas à se demander:

  • Qu'est-ce que je dois installer sur mon système pour pouvoir compiler ce logiciel

  • Quelles sont les commandes à lancer pour compiler ce logiciel

  • Comment est-ce que je l'installe pour ensuite pouvoir le tester



Et effectivement, pour les logiciels existants, n'importe qui devrait pouvoir écrire des fichiers de recette.
Vous avez dû voir que je privilégie le format JSON car c'est facilement analysable avec Hollywood ou Python ou autre.
Mais je pensais aussi que ampkg pourrait proposer une interface graphique facilitant l'écriture de ces fichiers.
Pour le côté facile à soumettre ta remarque me fais penser que j'ai pensé à un truc un peu compliqué.
Je suis bien sûr prêt à revoir ce à quoi j'avais pensé pour le rendre plus facile d'accès au simples utilisateurs qui voudraient écrire des recettes.
Pour rendre la publication de recette fluide, ampkg pourrait permettre, par un simple appui bouton l'envoie d'un fichier de recette.

Pour le reste de vos remarques concernant les fichiers d'installation j'ai du coup peur d'être passé à côté d'un "détail" d'importance.
Mais en fait je suis un peu partagé quant au lancement des Installer:
Je m'explique : ampkg doit connaitre exactement quels sont les fichiers qui composent un paquet logiciel (et aussi où ils sont installés).
Ceci pour pouvoir mettre à jour ces mêmes fichiers en cas de mise à jour du paquet ou pouvoir les effacer en cas de désinstallation du paquet.
Si je lance l'Installer je ne suis pas sûr de pouvoir détecter ce que cet Installer fait et ainsi détecter quel(s) fichier(s) il a copié et où.
C'est pour ça que dans les fichiers recette il y a une section INSTALL qui permet d'indiquer quel(s) fichier(s) doivent être installés et où.
Du coup ampkg garde la maîtrise.
D'un autre côté ça n'est peut-être pas très Amiga "friendly" de ne pas utiliser les Installer.
De toutes façons il n'y a pas de recette magique et il faudra faire des concessions.
Concernant la détection de l'Altivec ou autre (effectuée par les scripts d'Install ?), on pourrait très bien imaginer intégrer ce genre de fonctionnalités dans ampkg directement et enrichir les fichiers de recettes pour que certaines actions ne soit réalisées que dans certaines conditions (par exemple : installation d'un binaire si Altivec, un autre binaire sinon).

De plus, vous êtes peut-être passé à côté de ce "détails", mais je pensais qu'en fait ampkg aurait son propre format de fichier paquet.
Concrètement ce que ça donne pour un logiciel existant (sous forme de lha très souvent) : vous avez compris qu'il faudra un fichier de recette pour "packager" ce logiciel.
Mais en fait ampkg générera son propre format de fichier installable en faisant l'extraction du .lha et en incluant seulement ce qui est indiqué dans la section PACKAGED du fichier de recette.
Au moment de l'installation sur l'ordi de l'utilisateur c'est seulement ce qu'il y a dans la section INSTALL qui sera installé (et aussi ce qui est dans la section INSTALL_DEV si l'utilisateur veut également les fichiers utiles au développement d'applications comme les !include!s ou les librairies statiques).

Il n'est pas très facile par écrit d'expliquer tout ça et de se rendre compte si je n'ai pas oublié d'autres choses.

Ça vous dirait de se faire une petite session en visio un de ces jours en fonction de vos dispos?
Sûrement qu'en quelques minutes de conversation on se comprendra mieux qu'avec des dizaines de lignes de texte
J'aime bien Google Meet car ça fonctionne avec un simple navigateur (sûrement Chrome de préférence).
 Message édité par : BeChris / 22-05-2021 19:29
 Message édité par : BeChris / 22-05-2021 19:34
 Message édité par : BeChris / 22-05-2021 19:41
Papiosaur Papiosauricon_post
Je suis pas trop visio, mais je peux t'inviter à la maison pour qu'on en discute également.

Une après-midi ou journée dédiées à MorphOS :-)

On pourrait entre autre tester le dernier SWOS Total Pack :-)

BeChris BeChrisicon_post
J'ai proposé l'idée pour ze_bucheron ainsi que d'autres qui seraient motivés pour en discuter et qui n'habitent pas dans le 13
ze_bucheron ze_bucheronicon_post
Merci, mais moi qui n'aime déjà pas le téléphone, la visio, on n'en parle même pas, c'est vraiment pas pour moi désolé.

Par contre, j'espère que tu vas accepter l'invitation de Papiosaur, j'aimerais tellement que le meilleur d'Ampkg et de Morphos-storage se rejoigne pour nous offrir un outil efficace pratique et sexy.

J'ai vu que tu parlais d'une interface graphique pour simplifier au maximum l'écriture d'un fichier recette avec un bouton pour envoyer le fichier recette voilà qui va vraiment dans le bon sens j'adore.

Une petite idée qui pourrait peut-être être utile, qu'en pensez-vous ?

- Peut-être faudrait-il également installer un système de validation-confirmation du bon fonctionnement du fichier recette, avec un bouton choix offrant la possibilité aux utilisateurs de confirmer si l'installation à fonctionnée correctement ou non.
Par exemple, si mettons 2 utilisateurs on signalé un problème, le bouton change de couleur pour passer au rouge. comme ça n'importe quel utilisateur peut voir qu'il y a peut être un soucis sur telle ou telle archive et du coup refaire le fichier recette pour régler le soucis.

On peut même imaginer que si le fichier recette existe depuis déjà pas mal de temps, disons 6 mois ou un an alors la jauge du nombre d'utilisateurs nécessaire pour passer le bouton d'alerte en rouge devrait passer par exemple de 2 à 10 (à moins qu'on préfère ajouter
1 utilisateur de plus tous les mois).
BeChris BeChrisicon_post
Dommage pour la visio.

Et bien sûr qu'on va en discuter avec Papiosaure pour essayer de faire un outil de la mort qui tue.

Excellente idée pour le système de vote : je vais le noter dans un fichier séparé dont j'intégrerai les parties au fur et à mesure.

J'ai également traduit le README en Français pour faciliter la vie des anglophobes : https://github.com/BeChris/ampkg/blob/master/README_FR.md

A+
 Message édité par : BeChris / 24-05-2021 18:04
BeChris BeChrisicon_post
J'avance plutôt pas mal sur les choses à mettre en place: https://github.com/BeChris/ampkg/blob/master/README_FR.md
Il est maintenant spécifié qu'il sera possible d'indiquer des chaines de caractères dans différentes langues (pour la description du paquet mais pas que).
Il sera également possible d'effectuer certaines actions en fonction des capacités du processeur (avec ou sans FPU, avec ou sans ALTIVEC, même chose pour les x86 avec le MMX, SSE, ...).
J'avais d'ailleurs commencé un plugin Hollywood pour détecter tout ça mais que pour les processeurs Intel pour le moment : https://github.com/BeChris/Hollywood-sfp
J'ai pu voir dans le code de la SDL2 de BeWorld comment détecter l'ALTIVEC par exemple donc ça ne devrait pas être trop compliqué de gérer le PowerPC.
On pourra aussi spécifier de rajouter des lignes dans les fichiers comme S:user-startup, ...

Il reste maintenant à réfléchir sur les différents fichiers gérés par l'outil et où (fichiers de recettes et de base de donnée sur le serveur de téléchargement, paquets sur le serveur de téléchargement, base de donnée des logiciels déjà installés avec leur version sur le poste utilisateur, ...)

Et enfin réfléchir aux différents cas d'usage:

  1. Ecriture assistée d'un fichier de recette

  2. Test/soumission/approbation d'un fichier de recette

  3. Remontée de problèmes ou demande dévolution d'un fichier de recette

  4. Construction d'un paquet à partir d'un fichier de recette

  5. Et bien d'autres cas à penser ...



Voilà ça avance donc.

A+
BeWorld BeWorldicon_post
Bravo, ca me parait bien tout ca :-)
IMAC 2.1 / PB 1.5G 17 / PM G5 2.7
My Works
BeChris BeChrisicon_post
Citation : BeWorld
Bravo, ca me parait bien tout ca :-)


Merci mais ça va pas être facile de rattraper ton avance et écrire toutes les recettes pour pour tes portages :)

Je me posais d'ailleurs une question de taille et qui risque de me donner mal à la tête quand il va falloir détecter les paquets déjà installés sur le système:
Il va en effet y avoir un soucis par rapport à la gestion des versions.

Je m'explique sur un cas en particulier mais qui s'applique à pleins d'autres je pense:
BeWorld, si on prend en compte ta librairie SDL2 qui est en version 2.0.14 sur le serveur morphos-storage.
Du coup, ça correspondrait dans ampkg à un paquet SDL2-2.0.14-1 (j'explique dans le README les raisons du 1 en plus à la fin).
Oui mais quand on regarde les chaines "$VER" dans le fichier SDL2.library on y voit la version 53.3 : "$VER: sdl2.library 53.3 (18.5.2021) Bruno Peloille, Szilard Bir, Ilkka Lehtorant"
C'est une autre façon de versionner les librairies qui je crois est spécifique aux OS Amiga.
Du coup, quand je vais parcourir le disque de l'utilisateur et que je vais tomber sur cette SDL2.library comment je vais savoir qu'elle est issue de (par exemple) SDL_2.0.12_Libraries.lha ou SDL_2.0.14_Libraries.lha ou encore un autre lha puisque j'ai perdu l'info que ça a été généré à partir des sources de la SDL2 en version 2.0.12 ou 2.0.14?

J'espère ne pas avoir fait trop compliqué et que vous avez compris ma problématique :)

Une solution radicale serait que ampkg ignore complètement les librairies déjà installées (en indiquant par exemple qu'il installe tout sous un même dossier de départ) ou bien qu'il impose que l'utilisateur réinstalle son système de zéro.
Ainsi, si seul ampkg gère l'installation/mise à jour/désinstallation des paquets il n'y a plus de soucis.
Mais là je ne pense pas que ça ne passerait pas auprès des utilisateurs.
Papiosaur Papiosauricon_post
Je pense qu'il faut partir d'une version propre de MorphOS. "On" pourrait créer un fichier dans le répertoire sys:prefs/env-archives/ nommé ampkg.prefs qui pourrait contenir ce qui est actuellement sur le système. Chaque ligne de ce fichier prefs contiendrait la liste des packets installés.

Si on veut désinstaller, ampkg désinstalle le packet et supprime la ligne correspondante dans le fichier prefs.

Pareil, pour les mise à jour, le fichier prefs contient le numéro de version et la date et ampkg le compare avec la base de données citées précédemment (faire tous les soirs à partir de morphos-storage.

Des idées :-)