More April Extensions

Forum: The Testing Area
Topic: More April Extensions
started by: roberts

Posted by roberts on April 15 2006,22:39

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.

Posted by roberts on April 22 2006,06:08

Thanks to mikshaw a new icewm.uci is now posted in the testing area.

Posted by humpty on April 25 2006,17:14

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?

Posted by mikshaw on April 25 2006,20:34

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.

Posted by humpty on April 26 2006,04:10

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.