[pacman-dev] [PATCH v4] paccache: adding the possibility for multiple cachedirs
Either by specifing several -c parameters or only
one -c parameter with a comma separated value.
One could for example be for the official arch packages
and one for the aur.
Signed-off-by: Maxim Andersson
Why is the dir list comma-separated? The standard for *nix is to separate paths with a colon. On 08/27/2014 05:12 PM, Maxim Andersson wrote:
Either by specifing several -c parameters or only one -c parameter with a comma separated value. One could for example be for the official arch packages and one for the aur.
Signed-off-by: Maxim Andersson
On Wed, Aug 27, 2014 at 06:09:37PM +0400, Yanus Poluektovich wrote:
Why is the dir list comma-separated? The standard for *nix is to separate paths with a colon.
In environment variables, sure. Do you have an example of where this is done in a command line argument? I'm actually reconsidering my stance on the feature entirely, as it disallows cachedirs with legitimate "," characters in them. I think maybe it's sufficient to just accept multiple -c arguments (a feature which isn't actually documented anywhere but in the commit message and code). d
On 08/27/2014 07:55 PM, Dave Reisner wrote:
On Wed, Aug 27, 2014 at 06:09:37PM +0400, Yanus Poluektovich wrote:
Why is the dir list comma-separated? The standard for *nix is to separate paths with a colon.
In environment variables, sure. Do you have an example of where this is done in a command line argument?
Hmmm. Off the top of my head I can remember one — java -cp argument.
I'm actually reconsidering my stance on the feature entirely, as it disallows cachedirs with legitimate "," characters in them. I think maybe it's sufficient to just accept multiple -c arguments (a feature which isn't actually documented anywhere but in the commit message and code).
d
On Wed, Aug 27, 2014 at 08:02:49PM +0400, Yanus Poluektovich wrote:
On 08/27/2014 07:55 PM, Dave Reisner wrote:
On Wed, Aug 27, 2014 at 06:09:37PM +0400, Yanus Poluektovich wrote:
Why is the dir list comma-separated? The standard for *nix is to separate paths with a colon.
In environment variables, sure. Do you have an example of where this is done in a command line argument?
Hmmm. Off the top of my head I can remember one — java -cp argument.
Java is a really poor choice to argue with. Command line flags to Java look almost nothing like those in other *nix programs. At times, it even appears inconsistent with itself. For example: -Xmx10G -XX:+CycleTime -XX:AdaptiveSizePolicyWeight=50 These are most similar to "long options", but use a single dash which is the syntax used by "short options". The latter 2 also appear to use a ":" character to separate the flag name from its value, rather than the more commonly found "=" found in *nix flags. d
2014-08-27 17:55 GMT+02:00 Dave Reisner
On Wed, Aug 27, 2014 at 06:09:37PM +0400, Yanus Poluektovich wrote:
Why is the dir list comma-separated? The standard for *nix is to separate paths with a colon.
In environment variables, sure. Do you have an example of where this is done in a command line argument?
I'm actually reconsidering my stance on the feature entirely, as it disallows cachedirs with legitimate "," characters in them. I think maybe it's sufficient to just accept multiple -c arguments (a feature which isn't actually documented anywhere but in the commit message and code).
I feel it would be enough with multiple -c arguments. I added the comma-separated option so it would behave similar to the -i argument. If the comma-separated list is removed, should there be a note about the multiple -c option in the usage function?
d
On Wed, Aug 27, 2014 at 08:58:22PM +0200, Maxim Andersson wrote:
2014-08-27 17:55 GMT+02:00 Dave Reisner
: On Wed, Aug 27, 2014 at 06:09:37PM +0400, Yanus Poluektovich wrote:
Why is the dir list comma-separated? The standard for *nix is to separate paths with a colon.
In environment variables, sure. Do you have an example of where this is done in a command line argument?
I'm actually reconsidering my stance on the feature entirely, as it disallows cachedirs with legitimate "," characters in them. I think maybe it's sufficient to just accept multiple -c arguments (a feature which isn't actually documented anywhere but in the commit message and code).
I feel it would be enough with multiple -c arguments. I added the comma-separated option so it would behave similar to the -i argument.
I understand the rationale, but remember that "," is invalid in a package name (arguments to -i). Meanwhile, it's entirely valid for a path (arguments to -c).
If the comma-separated list is removed, should there be a note about the multiple -c option in the usage function?
Should probably be there regardless. d
2014-08-27 21:15 GMT+02:00 Dave Reisner
On Wed, Aug 27, 2014 at 08:58:22PM +0200, Maxim Andersson wrote:
2014-08-27 17:55 GMT+02:00 Dave Reisner
: On Wed, Aug 27, 2014 at 06:09:37PM +0400, Yanus Poluektovich wrote:
Why is the dir list comma-separated? The standard for *nix is to separate paths with a colon.
In environment variables, sure. Do you have an example of where this is done in a command line argument?
I'm actually reconsidering my stance on the feature entirely, as it disallows cachedirs with legitimate "," characters in them. I think maybe it's sufficient to just accept multiple -c arguments (a feature which isn't actually documented anywhere but in the commit message and code).
I feel it would be enough with multiple -c arguments. I added the comma-separated option so it would behave similar to the -i argument.
I understand the rationale, but remember that "," is invalid in a package name (arguments to -i). Meanwhile, it's entirely valid for a path (arguments to -c).
Yes, it's bad if paccache breaks when using a valid (but somewhat strange) path. I've removed the comma-separated option and updated usage() in a new patch. I also aligned the nocolor-option with the other long options in usage() and remove some leading whitespaces in parse_filename().
If the comma-separated list is removed, should there be a note about the multiple -c option in the usage function?
Should probably be there regardless.
d
participants (3)
-
Dave Reisner
-
Maxim Andersson
-
Yanus Poluektovich