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

[Andrew Gregory]

On 06/17/16 at 10:36am, Andrew wrote:
> 
> 
> 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:

Do package names ever overlap with local files?  Absolutely.  If
I happen to run pacman from /usr/bin on Arch, many of the executables
would overlap with the package that provides them.  Do package names
ever overlap with package archive names?  I have no way of knowing
that, which is why I don't like relying on convention.  pacman is used
on a variety of systems other than Arch.  I have no idea how they do
things.

> 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).

Something like this is probably fine for interactive use, but I still
don't like the inability to specify that a target is a package for the
sake of scripts that wrap pacman.

apg