[pacman-dev] [PATCH RFC] DWIM if user attempts to sync on a file

[Andrew]

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 at 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