On Fri, Jun 17, 2016, at 10:21 AM, Andrew Gregory wrote:
On 06/17/16 at 08:44am, Andrew wrote:
On Thu, Jun 16, 2016, at 11:19 PM, Allan McRae wrote:
On 16/06/16 10:01, Andrew Eikum wrote:
I get bit by this fairly often when I build AUR packages. From my perspective as a user, the distinction between -U and -S seems irrelevant: I just want to install this package. So let's just have pacman offer to Do What I Mean and install the files if I use -S when I should have used -U.
Signed-off-by: Andrew Eikum <coldpie@fastmail.com>
---
RFC because this lacks tests and maybe UI polish, but I thought I'd see if there's interest in this change before I put more effort into it.
I am interested... I have a more general comment. Why do we distinguish between -S and -U at all?
@Andrew: you are looking at unified transactions. Do you think merging -S and -U makes sense.
Speaking only as a simple end user, I don't see any distinction. Upgrade seems redundant. The Upgrade Options section of the manpage even says its options also apply to sync operations. The one distinction I can think of is whether the arguments are files, or package names from the repository. I guess if you had a local file named e.g. "qt" this distinction would be important; but I don't think that will occur in the real world.
So, another take on this patch would be to move local file and explicit URL handling into -S and make -U a synonym for -S, yes?
Andrew
I would love to rearrange pacman's UI and merge -S and -U into a generic install operation. I haven't worked on it in a while, but I would like to see something like this: https://wiki.archlinux.org/index.php/User:Apg#pacman_ui_reorganization
The problem with allowing -S to handle paths/urls is that package package names are also valid paths. Having pacman attempt to pick the one that makes the most sense by default would be okay, but users need to have some way to unambiguously distinguish between the two. I don't think that just hoping that package names never overlap with local files is enough.
Does this really happen? I expect all real-world packages end in '.xz', and no repositories will have packages named such. Even so, a straightforward and paranoid heuristic would be: 1) If the argument matches a repository package name, install that. 1a) If the argument also matches a local file name, warn. 2) If the argument has a protocol, do that. 2a) If the argument also matches a local file name, warn. 3) If the argument matches a local file name, install that. 4) Else, error. So, users who wish to install a local file named "qt" could pass "file://qt". This would even cover the insane hypothetical user who names their file "http://archlinux.com" as they can use "file://http:%2F%2Farchlinux.com". But maybe this is obscure enough that we don't even need (2a). Andrew