Connexion
Don't have an account yet? You can create one. As registered user you have some advantages like theme manager, comments configuration and post comments with your name.
Site activity

Pages showed since 06/01/2019 : 11 035 721

  • Nb of members 347
  • Nb of articles 2 521
  • Nb of forums 24
  • Nb of topics 13
  • Nb of reviews 0

Top 10  Statistics

Forum Index »»  Développement »» Développeur débutant sur MorphOS

Développeur débutant sur MorphOS#2209

5Contributor(s)
BeChrisze_bucheronBeWorldPapiosaurJedi
2 Moderator(s)
PapiosaurBeWorld
BeChris BeChrisicon_post
Merci pour toutes ces idées.

J'ai commencé à mettre en place dans le dépôt un fichier qui contient les fonctionnalités que l'outil devra fournir : https://github.com/BeChris/ampkg/blob/master/NEEDED_FEATURES.md
Et un autre, plus technique, qui indique quels types de fichiers seront stockés et où : https://github.com/BeChris/ampkg/blob/master/FILES_FORMAT.md

C'est pas fini et ça n'est qu'en Anglais : trop la flemme de maintenir des versions en Français :)

Du coup:
@Papiosaure : on retrouve ton idée de fichier contenant la liste des paquets installés mais plutôt sous une forme de base de données SQLite (plus facile à gérer je trouve et le SQL c'est puissant et très rapide pour permettre de faire des recherches dans la liste des paquets par exemple).
Et pour la prise en charge d'un système déjà installé on peut effectivement:

  1. Exiger une installation de zéro ce qui serait le plus facile pour l'outil

  2. Ou alors indiquer que ampkg ne gère que les installations/mises à jour/désinstallations qui sont faites par lui dans un dossier spécifique (Work:Applications_ext par exemple comme tu l'as mis en place avec le pack Crysalis).


Pour la détection des fichiers contenus dans les paquets on pourrait s'en sortir par l'utilisation d'un checksum MD5 que j'ai prévu d'intégrer.
Je pencherais plutôt pour la deuxième solution et les utilisateurs pourraient ainsi garder une certaine liberté avec des logiciels non encore gérés par ampkg (le temps qu'on écrire toutes les recettes) et progressivement éventuellement basculer sur du 100% ampkg.

@BeWorld : pour cette histoire de versionnage différent, après réflexion, on s'en sort aussi avec les MD5.
En effet on peut identifier n'importe quel fichier d'un paquet non pas par la chaine "$VER" qu'il contient mais plutôt par son MD5.
Tu pourras donc rester sur ton système de version ou changer ça n'aura pas d'impact :)

Concernant le découpage en SDL2, SDL2_image, ... j'y avais effectivement pensé aussi.

Avec Papiosaure on a eu la même idée de transformer le pack Crysalis en "simple" paquet.
Dans ce paquet, tous les logiciels initialement inclus dans le gros ISO deviendront des dépendances optionelles du paquet Crysalis.
Ainsi, l'utilisateur ne sera plus forcé de tout installer : il pourra sélectionner ce qu'il veut.
Autre énorme avantage : lorsque le pack évoluera, l'utilisateur pourra se servir d'ampkg et ainsi ne télécharger que les mises à jours entre deux packs : gain de bande passante et de temps !

Si on arrive à faire un outil rapide et fiable on va tout péter !
On va faire des envieux les gars je le sens
Papiosaur Papiosauricon_post
Je pense qu'il faut partir d'une version propre de MorphOS sinon ça va être compliqué je pense.

"On" pourrait créer un fichier dans le répertoire sys:prefs/env-archives/ nommé ampkg.prefs qui pourrait contenir ce qui a été installé 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.

voici un exemple de ligne de fichier ampkg.prefs

catégorie, lien de l'archive+nom de l'archive, numéro de version, date, chemin d'installation

Une idée comme ça en passant
 Message édité par : Papiosaur / 26-05-2021 10:47
BeWorld BeWorldicon_post
Le cas du package SDL2 n'est pas le plus simple à gérer, plusieurs bibliothèques inclus dans le fichier LHA.
Le package est là pour avoir un pack tout en un pour l'utilisateur final.
A mon avis, il faudrait que je découpe la SDL2, SDL2_mixer, SDL2_gfx, SDL2_net, SDL2_ttf, SDL2_image et utiliser le mode "release" de github par exemple.

Ensuite le cas du versioning des fichiers... comme 53.3 de la SDL2.library qui n'a aucun rapport avec 2.0.14 ? pq c'est comme ca....
En fait à la source, Itix c'est lui qui a créé la SDL2.library en version 53.0 basé sur la version 2.0.3, j'ai simplement continuer sur ce chemin pour garder la compatibilité...
Mais en effet comment détecter tout cela.....
Le pire c'est que je fais des mises à jour souvent du package SDL2 sans pour autant modifier la version lol.... (simplement la date change), ca risque d'être le bordel :-)

Tout cela pour dire qu'il faudra peut être s'adapter à ton futur ampkg et être plus "propre" dans le développement....







IMAC 2.1 / PB 1.5G 17 / PM G5 2.7
My Works
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 :-)
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.
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
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+
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
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
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