I have the habbit of addressing the most significant changes in the change log if I felt that the common courtesy demanded that. That means I write down some thoughts in that log file rather than only list the technical details of the changes.
> I can't understand why clive switched from being XDG standard > compliant to historical old-style configuration file location. Using ~/.cliverc instead of ~/.config/clive/clive, seems obvious to me and other like-minded command line dwellers. You can change the path for the non-config files by setting CLIVE_HOME or by using the --home-dir option if you are concerned about the home dir. This causes clive to write the misc. files (cache, recall) the specified $homedir rather than the default path. This was not very well documented in 2.2.0 but I've updated the manual page for 2.2.3. While I agree standards are important, it's however unlikely that any of these changes will trigger an apocalypse. As for the format, I wrote: "Config::Tiny has been replaced with Getopt::ArgvFile. The latter had some advantages over Config::Tiny that lead to the switch. For example, instead of trying to memorize the (often confusing) config variable names, users can now use command line options in the config file." "This also means that everytime a new feature is added to the program, we are no longer required to modify the code responsible for parsing the config file. Using Getopt::ArgvFile also required adding only one line of code to the project whereas Config::Tiny required several." -- http://code.google.com/p/clive/wiki/Changes Example: cat >> ~/.config/clive/config # clive 2.0 - 2.1 [http] proxy = "http://foo:1234" [output] savedir = "/home/user/videos" cat >> ~/.cliverc # clive 2.2+ --proxy="http://foo:1234" --savedir="/home/user/videos" As for the request, I have to say no. That is not a definitive "no", however. If support for the .config path can be implemented without changing too much the existing code, it will be done. Patches are always welcome. -- * I am not maintaining this package * I am not subscribed to this mailing list -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org