Bug#535483: clive: please switch back to XDG compliance for config file

Toni Gundogdu legatvs at gmail.com
Sat Jul 11 11:57:19 UTC 2009


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





More information about the pkg-perl-maintainers mailing list