The Testing Area :: More April Extensions



More interesting extensions and updates are now posted in the testing section of the repository.

Browse the .info files.

unionfs.dsl
madwifi-ng-2.4.26.uci
peerguard.dsl
timidity.dsl

A big thank you to the respective makers.

Thanks to mikshaw a new icewm.uci is now posted in the testing area.
Oh dear,
I just found out that when .dsl's are installed, they completely
overwrite files that are already there. This causes a problem with configuration files later changed by the user.

Currently the apps I submitted will be affected:
timidity
peerguard

Is there a way around this?

Otherwise I will have to hack into the app's code to get the app to generate the config files itself. But I don't really prefer this as it's a bit dirty.

Any suggestions?

One option is to not have personal configs (/home/dsl/*) included in the package.  I've seen a couple of applications that will choke if a config is not found (torsmo, for example), but most programs are coded well enough that they either create the appropriate files if they don't already exist or they use hard-coded default settings.  I couldn't say if timidity and peerguard do this.

Creating a wrapper to check for existing configs is easy enough, and not really too dirty.  As an example...
Code Sample
#!/bin/bash
[ -f $HOME/.timidityrc ] || cp /path/to/timidityrc-example $HOME/.timidityrc
exec /path/to/timidity

I'm just guessing about the filename.

One thing I'm concerned about personally is that you said "overwrite files that are already there".  Are you talking about files that are part of DSL?  You should NEVER do this unless absolutely necessary (such as upgrading an existing application).  I had a little argument about this a while ago with someone whose package overwrote personal configs, just so it would be "easier" to use.  After a few changes in DSL development, the package ended up breaking several users' setups.
If a package can potentially do this sort of damage, or simply cause unexpected changes to files that the user has put in the time to customize to suit his needs, then it's best to avoid making assumptions.  Just tell the user how to configure your package if you cannot safely do it automatically.

tks mikshaw!
i never thought about the wrapper technique. excellent.

that's right, this is only for the app's own config in home, so other files won't be touched.

Next Page...
original here.