Package: Yunohost

[mitra42]

There has been a request from @Nico for a Yunohost version.

Yunohost is intended for people wanting to host their own servers, picking and choosing from available servers. Its got a broader range of servers than IIAB if you are looking for communications (e.g. email, etherpad etc).

[mitra42]

Unfortunately the process for building an app is tough - which is probably why I see so many started projects not completed on their website. The docs for app building are in many cases

• out-of-date (e.g. refer to mailing lists dropped two years ago);
• out of order - you are following step by step, but the answer or link you need is down the bottom of the doc
• duplicative - you have to go though both https://yunohost.org/#/packaging_apps_guidelines and https://yunohost.org/#/packaging_apps in parallel to make sense of it
• lots of dead links - a mix of links that are just plain wrong (e.g. the one to the support forum) or go to the french version (which you can usually guess the english link).

I've got an open issue on https://github.com/YunoHost/issues/issues/1453 but its about a 1-day turnaround for each question since most of the active participants are in Europe (and I"m in Australia). so its cycle of take a couple of steps, post a question, put it back on the bottom of the to-do list.

Which is a long way of saying that porting to Yunohost is going to take a long time if noone is jumping up and down asking for it urgently, and its possible that it won't get completed, as its prioritised below platforms which are easy and/or well documented, and/or actively supported by a developer familiar with the platform.

[mitra42]

Note - if you want to help with this, its pretty unclear how to get support on Yunohost, not because there is no place to do so but because there are so many its hard to figure out where to ask, specifically try: https://github.com/YunoHost/issues https://forum.yunohost.org and via Matrix #freenode_#yunohost:matrix.org

[nico]

I have no memory of requesting this.

[mitra42]

Thanks Nico - my apologies, it was you and Karel who discussed it on apc.tech and somehow got into my list with your name against it :-) maybe because it seemed like it might be being suggested as a host for community networks. Given how badly documented the integration process is, I'll hold off unless someone else is using it.

[pedro-nonfree]

( @mitra42 you meant @nicopace )

Due to that conversation in apc.tech mailing list (which I'm there too) I tried a new mail service with yunohost and it worked fine.

As yunohost is based on debian, what we can make for sure is install dweb-mirror on top of that debian

[mitra42]

Ah - thanks - wrong Nico :-)

Yes - I don't think installing on top of Yunohost, there are too big issues 1: Their docs are at an early stage ! I found a bunch of errors just doing the install and the first few steps of the process, so the install won't be hard, but working in with their package system is going to be a pain, if the rest of the process is as badly documented as the first part (for example you have to follow through both the step by step instructions and the "guidelines" which are in a very different order at the same time, and both contain inaccurate information.

2: They use a version locking system (including hashes) which means that you can't have an install process that gets the latest version of dweb-mirror, so anyone on Yunohost, even if they update regularly, will be running an old version with bugs that will have been fixed and pushed. This means it won't be supportable in any way, since you wont be able to tell someone to update and see if the bug is still there. I've raised this on https://github.com/YunoHost/issues/issues/1453 but that line doesn't appear to be going anwhere.

So at least for now - until Yunohost fix their docs, and/or there is a real need, I've put Yunohost down the bottom of the priority list.

For now ... it should work better anyway just to run the installation instructions for other platforms. In that way you can also update to the current version when you hit problems. (I'm on a very fast report-fix-release cycle)

I'm just about to merge the install scripts, so if you are planning on doing this, let me know here, and give me a day or two and there will be a new version of the install script that hopefully will just work on Yunohost anyway.

[pedro-nonfree]

In my perspective the most important conflict is between yunohost debian-stable-like versioning and that dweb-mirror don't have releases yet and the later commit the better. I don't know if you plan at some point to make a release when the very fast report-fix-release cycle reaches peace.

Hence, adding dweb-mirror in its current state to yunohost makes no sense to me.

[mitra42]

Define "release" in this context? Do you mean a version which you would recommend people to install in preference to the latest NPM version ?

Note - I definitely wouldn't point people at the latest commit, commits (on Github) are for developers, NPM versions are recommended installs, and the latest NPM version should always be better than the previous, which is the difference between NPM style versioning and Debian-style versioning.

Formal "release" would apply if and when there are enough people inolved in the open-source to do the thorough testing that distinguishes between alpha/beta users, and regular users, but even at that point the semver locking on NPM works well in locking people to updates they should get.

It would make sense to allow people using, or at least trying, yunohost (and there some in the APC Locnet team) to install on top of Yunohost, but unfortunately it makes no sense to support Yunohost with an installer if Yunohost is going to lock them to an old (buggy / unsupportable) version.

[pedro-nonfree]

I did not know you have the releases in the npm part

that is the situation for yunohost packages like gitlab and nextcloud with lots of releases

do you have a workaround that checks if there is a new version and makes it visible for the user-systemadministrator to encourage the upgrade?

for the yunohost case, you could say that you are open to include it there, but it requires another person (not you) to have the role of "yunohost maintainer of dweb-mirror package"

[mitra42]

I think (could be wrong) that its a two step process. a) Yunohost should allow a NPM hosted package to upgrade (and the upgraded could be via the yarn, or npm tools - which should be a package choice, they aren't quite the same, but both will only upgrade if the package on NPM matches the semver locking rule in its package.json file, b) a way to check whether the package needs updating to provide the info you suggest, I would have thought yarn and/or npm have a way to do this, but its not immediately obvious how.

I think both of those are a yunohost<>npm interaction independent of internetarchive.

Note that I didn't get very far in the process of building the internetarchive app on yunohost, I hit so many documentation bugs in just the first few steps that I gave up until they get the documentation at least reasonably accurate.

[nicopace]

I just wanted to jump in and say thanks to @mitra42 for the hard work he put. It is indeed frustrating when things are not as ready for the devs as they are for the users. From a user perspective Yunohost works very well, but it seems it is not that easy for devs. Hope this changes in the near future. Again, thanks!!!