Je trouve plutôt que c'est bien moi :-D

Sauf les trucs qui possèdent un SDK qui doit être installer plus exotiquement...

Yop,

Un programme qui s'installe proprement, c'est un programme qui demande rien à personne...

-> désarchiver le répertoire quelque part et ça roule : pas d'assignation, pas de composants supplémentaire (bibliothèque, classe etc...).

Si il est nécessaire d'installer des bibliothèques supplémentaires, une fenêtre de requête doit s'ouvrir indiquant la dépendance manquante ou alors fonctionner en mode dégradé (c'est à dire en se passant du composant manquant) tout en informant l'utilisateur de l'absence du composant.

Sinon, c'est toujours sympa de voir de nouveaux logiciels arriver. :)

/me en restera à l'installation manuelle...

++

Je trouve ça cool aussi, tout ce qui peut me permettre d'etre plus feignant est bienvenue :-P

APrés comme disent les autres, les deux soucis c'est :

1) quid de la maintenance de la base de donnée/dépot sur la durée
2) le soucis des logiciels qui demandent des dépandances

@Tcheko: un programme n'est pas toujours qu'un simple binaires avec qq data n'appartenant qu'Ã lui!
Mon exemple n'est pas pris au pif: python c'est un programme (l'interpréteur), une bibliothèque partagée (devant être accéssible depuis tout autres programmes), un SDK (!include!/lib) et un ensemble de scripts vu comme des outils à part entière!

Pas 1 truc au même endroit! Comment on fait dans ce cas lÃ?

I write in English because google translation suckz ;)

Ok, I read the stuff above and it seem I need to clarify a lot :D

First, I am not stupid and I saw the failures before, trying to set-up a working
packet manager system which is accepted by the people and by the developers.

That's why I usually do a brainstorming about what I need and what I want. Yes, I
am selfish here, because if I do not need something its boring to program it.
That's work and I want a little fun. Back to the topic.

I came up with a list why those other systems failed:

1. Servers

Servers are a good thing, but can be a pain in the ass if they are not or no
longer available.

2. Support by the developers

Developers needed to support a packet manager or software was not be able to be
used with the manager.

3. Repacking

It was always needed to repack the software which made it complicated.

Those three points killed those projects, even before you look at the software
itself, which may been great. I did not look at it ether.

So what is my solution? Well, Server are good, but should be easy to replace.
Support by the developers is good, but if he does not care about the project it
should be fine, too. And no repacking!

Stupid? Only on the first look I inverted the first points from good to bad.
Lets start with the second one. Its not bad to have developers supporting such
Software, as long as they like to. It is help. Speaking about help. There are
hundreds of people out there able to maintain their system by hand. Why not
allow them to participate to help?

This is the big goal. Everyone can help. Back to the servers. Servers in this
case are simple http servers. Nothing special, but centralized enough to feed
the masses out there with new data files.

Some people are translators and love to fix and update catalogs, while other
love to use them. A database file on a server and zwoosh. Quick interaction
without any need of placing the files inside a global database.

Yomgui mentioned the maintaining of the database. Or in other words: What
happens when geit sits dead in his chair? The solution would be easy. Someone
would take the latest database change the URL inside to his webpage and uploads
it. The users now are able to download the file once and place it into their
Grunch drawer. From now own the database is under control of that new guy.
Simple isn't it?

Speaking about the database and the time needed to update by the non dead
maintainer. Everyone is able to set up a server (its a file on a webserver, can
even be an Aminet text upload) for his own needs. If a developer wants to ensure
the installation is done as it was meant by him, he provides a self updating
database on his pages. The user can download the file, place it into his Grunch
database folder and from now Grunch updates stuff from that developer direct.

Well, I talked about updating a lot and you may say "yeah its a packet manager".

It is not!

It's more than that. People talked about setting up an AppStore for MorphOS or
AmigaOS. Well, there was much laughter, but frankly its nice to have a central
point, where you search for software and a click later it is installed. (iPad
user speaking). This thing is a more flexible way than Papiosaur's Pack
Ultimate. The pack is nice and helpful for new people, but it contains so much
nice software which cannot be seen by people already have there set-up system.

And yes I did not install the pack, but downloaded it to simply drag over the
stuff I needed. Grunch is (will be) kind a software store where you search for
stuff and install it or if you want to uninstall, that can be done, too. Today I
got noticed about the OWB update by Grunch and a single click later it was
installed. Even that click can be avoided by disabling update requests, as you
can see on the image above in papiosaur´s post.

It's also connected to Magic Beacon, which means you´ll get notified on updates
and updates get downloaded automagically if you like. So even if you want install
by your self this tool is nice to have.

Tcheko mentioned the dependency problem. This is a real problem not only on
MorphOS. Grunch knows dependencies in current version. So if you want to install
a game which needs powersdl, it will check if it is installed and if not a
requester will pop up and show the dependencies of the application. If the user
continues powersdl gets installed, too. If he cancels the software installation
gets aborted. There is no dependency support for on uninstalling. If the user
decides to uninstall powersdl, it is his choice. Afterwards the games will fail,
but when he simply reinstalls one of them, he gets informed that powersdl is
missing and the system repairs itself. In my opinion this is the best way to go.

One more thing: (yeah stolen)

I only have a few testers right now, as it is required to have some experienced
people to find the flaws and bugs as well as provide ideas of features I forgot.
So far they seem to be happy with the result and the number of applications in
list is that small, because I asked them to now send any in until the database
format is settled. :)

Geit

@Geit:

Wonderfull that you've started to explain it.... try to write that on a wiki with comments capacity!
Everyone can participate to the brainstorming! ;-)

Now one thing not explained: how grunch knows how to install stuff? sort of scripting stuff?
You've not explained also your third point: no repackaging. what do you mean by?

Finally, the server maintainance is not so comlicated in grunch is able to make its own local database view,
using multiple server databases: redundancy, robustness, etc...

Well, since the application most mostly done, I don´t see any point in making the stuff that open. Parts of this text will be used in the manual.

About your question. Yes! It´s simply a dos script for unstalling and deinstalling in each database entry. I did not want to make it over complicated. The scripts contain placeholders for version, path and other information, which will be filled by grunch before execution. In most cases installation is just dropping an application folder and/or some libraries. A script is fine here. If an application needs a more complex way of installing its also possible to launch the archive !!!include!!!d installer script.

Repacking is required by some packet manager systems to !!!include!!! contents or install information. This would for example made the entire aminet useless, because non of the old files will ever support a new packet install mechanism. It also would effect 100% of the existing software out there. As you can see in my OWB example it works, even if Fab has no idea it does :)

I could even use your blog to create an packet for your helios. Well, a blog that looses information at the ed is not the best choice, but it would work.

About server robustness: geit.de is stable and a proper source for the startup database. I would prefer to keep it like for now, to avoid trouble with different entry's from different people for the same stuff.

Geit

It explains a lot of things, and it's EXACTLY (well, more or less :-P) what I was looking for (and, actually, begging for on meta morphos.org ;-)) .

Thanks for develloping such a software. Can't wait to test it :=!

"""
Finally, the server maintainance is not so comlicated in grunch is able to make its own local database view,
using multiple server databases: redundancy, robustness, etc... """"

Carrément. Ca permet aussi, si on développe une application qui évolue trés vite, au dévellopeur de faire son propre database de béta versions, par exemple. Ainsi, on aura (nous les utilisateurs) toujours la derniere version en date, si on le souhaite, ou alors on conserve la version "officielle" via le greunch db principal.

C'est vrai que ça ressemble beaucoup à un packet manager :-P et tant mieux...Si ça roule comme Geit nous le dit.

Absolutly. It also allows a develloper to create his own database, to purpose up to date beta versions of his creations, for exemple. So the user can use the last beta version (using the dev grunch database) or the "official" stable release (using the main grunch database).

It's true, it sounds like a packet manager :-P And, in my opinion, it's a good thing...especially if it works as Geit described it.




PS :

I've got a question : from where grunch will download the software ? From devs websites, or from websites like Mos2depot, aminet, morphosfiles.net, etc... ?

Maybe it would be possible to add a function in Grunch to search for the software itself ? For example, if OWB official website is offline, maybe Grunch would be able to search it from another online location ?

Grunch downloads the software from the location specified in the db entry and that can be anywhere, as long as it is plain http access.

Adding more sources to the database would be possible, but this is more complicate than you thing, as filenames and versions of those archives may defer.

Currently I prefer the external way without making the tool more complicated. If a page tends to fail from time to time, it is always possible to simply clone the existing script, change the name, urls and add it. Now the grunch has two server versions for the same software available for version check and the first one which updates and is available will win.

As you can see on papio screen shot did this with Grunch already as I have a beta and a standard version !!include!!d, which are the same on system, but different out there. As you can see there is a new beta available, but the release version on server (a fake readme) is at 0.1. Just don´t get confused about the window title. I used the grunch binary from inside the source drawer and not the binary reported being outdated.

Geit