-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Package: Yunohost #259
Comments
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
I've got an open issue on YunoHost/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. |
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: |
I have no memory of requesting this. |
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. |
Ah - thanks - wrong Nico :-) Yes - I don't think installing on top of Yunohost, there are too big issues 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 YunoHost/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. |
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. |
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. |
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" |
I think (could be wrong) that its a two step process. 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. |
I just wanted to jump in and say thanks to @mitra42 for the hard work he put. |
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).
The text was updated successfully, but these errors were encountered: