Questions on building extensions
Topic: Questions on building extensions
started by: Juanito
Posted by Juanito on Nov. 04 2007,12:41Looking at some recent extensions in testing, it looks as though user.tar.gz is being used in uci extensions to place symlinks in /opt/bin to point to executables in /opt/myapp/bin.
If this is the "right thing to do", is /opt/sbin required for executables in /opt/myapp/sbin or could symlinks be used from /opt/bin to /opt/myapp/sbin? (I presume they could, but is this a good idea?).
In order to be able to edit various .conf files in uci extensions, I've used symlinks to point from /opt/myapp/etc to /etc in a couple of extensions I made recently. Whilst this allows the .conf files to be edited, they have to either be packaged in a separate dsl extension or duplicated in /tmp (for example) using user.tar.gz and then copied across.
Is there a better way to handle .conf files in uci extensions?
I've also made symlinks from /opt/myapp/var to /var as some applications need to write files here and the ro nature of uci extensions does not permit this. Usually this is not a big deal, but sometimes applications fail because they require a directory /var/xxxx to exist.
Prior to loading an extension for the first time, the directory /var/xxxx can be created and added to the backup, but is there a better way?
Posted by mikshaw on Nov. 04 2007,14:55
Posted by roberts on Nov. 04 2007,15:13uci files dependent on .dsl is not what I had in mind. uci are supposed to be self contained and writing only to /opt and /home/user Using a .uci should not have to invoke mkwriteable via a dependent .dsl
creating dependencies get messy and is confusing for the user.
The .unc was created when self contained was not possible and where write capabilites are need spread throught the file system it saves ramdisk space like the uci, otherwise make it a .dsl Of course .dsl are very heavy on ramdisk.
user.tar.gz within a uci is still the same in v4.0
Posted by Juanito on Nov. 04 2007,17:49
- like /etc/cupsd.conf, /etc/smb.conf and so on. Basically files that the user needs to modify, which means that they cannot be left in /opt/myapp/etc.
- I hadn't thought of that - thanks. This would be most obvious to do from an icon, but no so obvious to do (but still possible) for a collection of applets (eg bluez-utils) or a daemon (eg cupsd)
- the idea here was only to use a dsl once to populate /etc with the necessary conf files which would be added to the backup and the dsl deleted. The conf files could be copied to /home/dsl from user.tar.gz and then manually copied to /etc and added to the backup, but then they would appear in /home/dsl every time the uci was used (not too big a deal I guess).
Posted by mikshaw on Nov. 04 2007,19:05
Of course in these cases the symlinks and the actual commands would have the same filenames, so they couldn't be in the same directory. This isn't really important, though, since you could simply create the symlinks in /opt/bin
Another option would be to make a wrapper for each applet, but that's just busywork.