Step 2: build your package
It’s time to build your package. Let’s build htop for instance, a nice replacement for top command. The example will build it for the scenario 64k-wheezy (i.e: packages suitable for 4.x firmware, built from the version of htop provided by Debian Wheezy). Start your build system, login, then:
# sudo su
# cd /root/wdmc-build/64k-wheezy
# ./build.sh htop
The built package will be placed into /root/wdmc-build/<scenario>/build/root and will consist of one or more .deb files (you’ll also find other files and folder, just ignore them and consider only .deb files). Sometimes building a package will build other packages, too: it depends on how package sources are organized. For instance, if you build transmission-daemon, you’ll also get the deb packages for the GUI packages (like transmission-gtk or transmission-qt): you can simply throw away those additional debs if you don’t need them.
Once the deb files are ready, copy them from the build system to your My Cloud (to achieve this, if you built a VirtualBox VM you may use a shared folder to exchange data with the physical host system). Then, login via SSH to your My Cloud and type:
# dpkg -i <path-to-build-deb-file>/htop_1.0.1-1_armhf.deb
where <path-to-built-deb-file> is the path where you stored the deb file you just built; if you copied it to the standard Public shared folder, the path will be /shares/Public/.
If you’re lucky, you’re done. Otherwise, the /installation command may prompt you something like this:
dpkg: dependency problems prevent configuration of transmission-daemon:
transmission-daemon depends on libcurl3-gnutls (>= 7.16.2); however:
Package libcurl3-gnutls is not installed.
This simply means that the package you’re trying to install depends on another package (in this case: transmission-daemon requires libcurl3-gnutls) which is not yet installed. You then need to build in turn this required package, with the same procedure, and install it before the package you originally intended to install. Repeat the steps for all the missing dependencies that dpkg reports. Sometimes, to fix circular dependencies (packages depend on each other), once you’ve built all the necessary packages you may install them all at once with: dpkg -i <path-to-built-debs>/*.deb, so that dpkg will resolve dependencies automatically.
Final notes
- building a package may require a LOT of time, just be patient…
- you may periodically clean /root/wdmc-build/<scenario>/build/root folder after you’ve built your packages, to free up space; in fact, building may require a considerable amount of (temporary) disk space
- once installed with dpkg, packages contents are unpacked to the My Cloud system partitions. There should be enough disk space available to not worry about disk space, however almost certainly a firmware upgrade will delete all of your installed packages; I would suggest to create a shared folder using the web UI, named “System”, protected by password and accessible only to admin users; inside it you may put your built deb files, organized as you like. In case of a firmware upgrade, you may simply re-install the packages from there using dpkg -i (one at a time, or all of them at once using wildcards, etc.); however please consider the following notes
- a firmware upgrade might change the architecture of the provided Debian system and might require to rebuild all packages… this is exactly what happened with the upgrade from 3.x to 4.x firmware, where WD decided to rebuild the whole system using 64k sized memory pages rather than the standard 4k sized ones… I don’t think WD is so sadistic to do that again and again, but who knows? I suggest to read carefully the release notes of the new firmware, have a look to the updated GPL source package (if they make it available on their website) and try to install a few small packages after firmware upgrade just to check that everything is ok; installing all in a rush may have catastrophic effects, especially when a package you had built on your own requires to update one of the WD provided ones… if it won’t work, it will almost certainly break something of the WD built-in features, causing a device failure in the worst case… again, you are on your own, you get no support for this
- to restore the whole functionality of third-party applications after a firmware upgrade, not only you may need to reinstall the deb packages, but you will also need to restore any custom application configuration; if you leave default settings, usually applications save their settings in /etc or in /root, which are both on the system partitions of WD and might be deleted and recreated by the firmware update process; you may choose to backup your application configurations or change things so that they are linked to a shared folder (for instance the aforementioned System shared folder) where they won’t be deleted; in this way, after the firmware upgrade you may just need to restore your backups or your symlinks; howerver, the exact procedure may be different for each package and is above the scope of this guide
From the above, two things should be quite clear: disable the automatic firmware upgrade in the web UI and use all of this at your own risk.
Feedback, improvements and corrections are welcome.
UPDATE ON 2015-01-10: I’ve published a new message where I’m providing patched scripts and an updated binutils package to make the build environment work better, especially when building packages from jessie repository and with 64k pagesize. Here is the direct link.
