News about app management and packaging in YunoHost 2.4

Dear app packagers and maintainers,

Here is news about apps management and packaging enhancements which have been release in YunoHost 2.4.

One of the power of YunoHost is the multitude of available applications easily installable. Official apps are maintained by YunoHost team. Other applications come from the Community, which means there are maintained by one person without been tested and maintained by YunoHost team. It does not mean they are not working and the package is poor quality, quite contrary.

Maintaining applications is a regular workload, because we need to follow updates of the upstream project. YunoHost development team try to focus on a limited quantity of applications. You can bring your help. Competences to maintain a package are the same as the one used to manually install an application: knowing a minimum admin sys and Shell commands.

Do not hesitate to contribute. More information in documentation.


Packaging documentation

Packaging documentation has been updated and still need more enhancement to be more friendly for new packagers.

Apps management

We have moved the list of available apps from documentation to this repository.
If you want to update, add, remove a package you’ll need to do a pull-request on this repository.

If you want to submit your app to be an official app we have updated the process to do so.

YunoHost-Apps GitHub organisation

Package linter

A package linter checks whether your apps’ manifests are up to date, scripts, some coding standards and various other things. Feedback is welcome.


News about YunoHost 2.4 release for app packaging

  • packaging format: new manifest key, which introduce a “package format version number” so we can modify how app are packages while keeping a bit of retro-compatibility if needed, document how to upgrade and refuse to install to old not upgraded apps.
    The “bind apps to yunohost version” is the Firefox approach where all your plugins breaks at every upgrade, we don’t want that for our users apps. This approach is more like the Chrome one: decorrelation between YunoHost version and package version, this way, as long as we keep things in the same way in YunoHost apps won’t break with a new version and if we need to change that we will be able to do easy to follow documentation for that. This will reduce the cost of doing a release for YunoHost.
   "packaging_format": 1,
  • requirements: new manifest key, which allows to specify Debian packages - and their version - that must be installed on the system. Here is a quick overview about its format. It is still a work in progress, and will surely manage the installation/upgrade of those packages in the future - providing a way to fix app’s package dependencies. Considering the first point, e.g. your app is multi-instances, you should add this:
     "requirements": {
         "yunohost": ">= 2.4.0"
     }
  • Multi-instance (applications that can be installed several times):

  • with YunoHost 2.2, we were doing dirty sed in the script the app_id to app__1, app__2.

  • with YunoHost 2.4, you have to retrieve the last parameter given to the script with app=${!#}.

  • This is a backward-incompatible change: the multi-instances apps that were working with YunoHost 2.2 will not be installable on YunoHost 2.4

  • New way to retrieve arguments have been added. For that, we will use environment variable for instance: $YNH_APP_ARG_DOMAIN = domain.tld. Multi-instances environment variables will be generated. The other way to retrieve arguments is not removed.

  • Backup system is now mature enough to be used for apps: backup and restore scripts examples.

  • During app install, upgrade, remove from shell, you won’t see the logs anymore. For that you will need to use the --verbose option to see install logs for instance.

  • New shell helpers are available to ease packaging, in particular for common tasks like password generation, MySQL database creation… Examples are available in the example application. We advise to use them.

  • Remove script is launched if install script fail with exit 1.


Mailing list

We did not communicate much about our new Apps Mailing list.
If you want to have latest information about packaging in YunoHost, and discuss with other maintainers, this is the good place. We invite you to subscribe to it.

Bug tracker system

We also have a new centralized bug tracker system where you can find and fill tickets regarding YunoHost development. Don’t hesitate to use it and to join us in the discussion and even in the development on YunoHost!

Contribute

Don’t hesitate to join the mailing list and start a thread if you have any questions.

Future discussions can be done on the the mailing list. You are also all warmly welcome to join the XMPP dev chat room (dev@conference.yunohost.org) to shape the future of YunoHost with us!

Thanks

And we would like to thanks you all a lot for your contributions on YunoHost, it wouldn’t be the same without you :heart:

@beudbeud, @Bram, @jerome, @juju, @kload, @ljf, @opi, @Maniack_Crudelis, @Moul, @scith, @titoko, @tostaki, YunoHost team, app packagers and maintainers…

6 Likes

Je suis vraiment impressionné par la stabilité du cœur applicatif
par exemple, avant avec 2.0 et 2.2 j’avais des erreurs lors de la désinstallation, chose qui à priori est super bien géré par la version 2.4. J’ai pu tester amplement la désinstallation car beaucoup d’application demeure non compatible avec cette version.

Autre amélioration que j’ai remarqué, c’est du côté de la résolution DNS;
J’ai toujours tenté faire un sous-domaine par application et c’est la première fois que c’est stable :wink:

Sincèrement; malgré le peu d’interrelation entre les applications déployées; vous offrez nettement plus que Cozy, sandstorm, …
Plus de stabilité, plus de choix, plus de flexibilité en plus d’être plus transparent que Cozy vis-à-vis les développeurs d’applications.

Merci pour votre bon travail et continuer à utiliser, reporter des bugs, développer, … à croire en l’auto-hébergement.

2 Likes