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...
Activité du Site

Pages vues depuis 06/01/2019 : 520 892

  • Nb. de membres 352
  • Nb. d'articles 2 553
  • 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

5Contributeur(s)
BeChrisze_bucheronBeWorldPapiosaurJedi
2 Modérateur(s)
PapiosaurBeWorld
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 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
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