Apps :: Questions on building extensions

Looking 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?

Quote

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?

Consider the fact that in DSL user dsl already has the sbin directories in PATH, and that most administrative stuff is done with "sudo <command>" rather than logging in as root. I don't think linking /opt/myapp/sbin files into /opt/bin is going to be a problem.

Quote

Is there a better way to handle .conf files in uci extensions?

I think you're going to have to explain a little further what you mean by .conf files and what you're doing with them. Configuration files are application-specific, so usuually what you do with them depends on the app. I also believe that the use of user.tar.gz has changed a little with DSL4.0, so I'd need to look into mydsl-install to find out for sure what's happening.

Quote

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?

I generally use a wrapper script to create vital files. The wrapper is used in place of the actual executable. Basically, the wrapper checks for the existence of /var/xxx and creates it if it doesn't exist, then runs the application:

Code Sample

[ -d /var/xxx ] || mkdir /var/xxx
exec /opt/myapp/sbin/command

uci 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

Quote

I think you're going to have to explain a little further what you mean by .conf files and what you're doing with them.

- 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.

Quote

I generally use a wrapper script to create vital files.

- 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)

Quote

Using a .uci should not have to invoke mkwriteable via a dependent .dsl

- 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).

Quote

This would be most obvious to do from an icon, but no so obvious to do (but still possible) for a collection of applets

One solution is to include a check for $0 in the wrapper and make symlinks to it using the names of the various applets. When you use a symlink, $0 (the name of the command) will be seen as the name of the symlink rather than the name of the script.
example:

Code Sample

[ -d /var/xxx ] || mkdir /var/xxx
case $0 in
*/some_command) exec /opt/myapp/bin/somecommand;;
*/other_command) exec /opt/myapp/bin/othercommand;;
esac

or:

Code Sample

[ -d /var/xxx ] || mkdir /var/xxx
my_command=`basename $0`
exec /opt/myapp/bin/$my_command

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.

Next Page...
original here.