_For new Package Requests, see the guidelines_
_Package Name:_Nano
_Package Version:_Last
_NAS Model:_ds3615
_NAS Architecture:_bromolow/dockerx64
_DSM version:_6.2
Nano architecture docker64 support
Package is not available in package mgr
_1._Just look in package mgr / synocommunity
N/A
Insert the package log here
N/A
N/A
Insert log here
There is a nano package available for your Nas.
I don't understand what you mean by a docker64 package.
None of the packages from the SynoCommunicty are docker images, they are packages that should be installed on the Nas itself, and cannot be installed in a docker.
If you want such nonsense as a docker image with Nano in it, you have to find it elsewhere in a docker repository
Hello. dockerx64 is a Synology architecture for DSM 6 running as docker image.
I have no idea why it was not included in April build. So I will publish an upgrade at the same time
Aha DSM in a Docker, still more useless nonsense.
I did not know such thing existed.
What's next a VMM on a DSM docker on a Nas?
Why not... but Synology proposes DSM as docker container to reduce VM performance penalties: https://www.synology.com/en-global/dsm/feature/docker
It is indeed ligthweight, even same almost same performance as the host.
I use it for testing purposes.
And indeed, the question is to add the dockerx64 architecture.
But why not use the package on the Nas itself.
You can install, test and remove any package.
The whole point of packages is exactly the same as a docker image except that docker creates an overhead of an extra OS hat is running on the Nas.
And I have seen many, many problems with application running in a docker.
The Idea of Docker is that you can create a docker image and that could be installed on any OS that has Docker support so you could run an application that has no native support for the OS you are using.
But if there is a native package, it seems silly to run it in a docker (with the native OS in it) to run a native package.
That's layer upon layer without any usefullness.
Of cause I installed it on the host dsm. But it is not automaticly available in docker DSM then (DDSM).
The files of DDSM are only reachable from DDSM and not from the host (hidden there somewhere and not advisable to edit from there).
As I said not a very usefull feature that DDSM.
@ymartin59 The package does not have a correct start-stop-status script.
It returns the status 3 instead of a 0.
I can confirm the problem with the "status" returning a 3 instead of a 0" on a Atom C2538 architecture. I also noticed that the changelog of the 2.9.8 release is still that of the previous release.
I noticed that a downloaded and manual installed package has the correct returncode of 0 instead of 3.
I just installed nano and package remains in "stopped" state even if I trigger "Run", which is expected as it is not "startable".
OK I have published "too fast" and forgot change log. But I will no redo just for that.
I disagree. The state "Stopped" is very confusing as all other similar packages that only add shell commands (Python, Git, PHP etc) give a status "Installed". The previous version of nano returned 0 when the status was asked in the 'start-stop-status' script.
The best thing seems to give nano its own "dsm-control.sh" script, like the python3 package has in the source.
Okay, nano works in this new package, and the problem is mainly cosmetic in PackageCenter.
@ymartin59
The packages that have no deamon and who are not startable should return a 0 and not a 3 when asked for its status.
When you return a 3 as the status of the start-stop-status script, then the package center will show the package as "Stopped" and you get the option to "Run" it which is pointless.
So all not startable packages like Nano, ffmpeg, python etc etc should return 0 and not 3 as their status.
If the return is 0 then the status in the package center will be installed and the only option you get, will be "Uninstall".
The action "Run" will not be available then and that is how it should be.
@BenjV Correct. This recent change comes from #3387 discussion... and I misunderstood how to handle non startable packages
Most helpful comment
@BenjV Correct. This recent change comes from #3387 discussion... and I misunderstood how to handle non startable packages