[pacman-dev] Merging -S and -U - Was: DWIM if user attempts to sync on a file

Andrew Gregory andrew.gregory.8 at gmail.com
Thu Jun 23 12:38:59 UTC 2016


On 06/23/16 at 10:29am, Allan McRae wrote:
> On 18/06/16 01:21, Andrew Gregory wrote:
> > 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
> 
> That seems a big change!   I think merging -S and -U could be a start
> along that path which can be done now without a major shift in the way
> we do things.
> 
> > 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. 
> 
> My proposal is repo package take priority (in standard pkgname then
> group order - which also has issues!), then files.  Conflicts can be
> handled by doing:
> 
> pacman -U file:///home/arch/pkgcache/glibc-2.23-5-x86_64.pkg.tar.xz
> 
> or is providing a full path enough?  I don't think we allow "/" in
> package names...

Any target that begins with or contains multiple '/' can't be
a package.  Groups, however, are arbitrary text.  The only things they
can't contain are '\n' and '\0'.

I would feel better about merging the two if there were a way to
specify that a target is a package, at least for the sake of scripts
that wrap pacman.  If the package doesn't actually exist in a repo,
trying to fall back to a file, whether it's a package archive or not,
would likely be a point of confusion.  We already have ambiguity
between packages and groups, adding files to the mix just makes it
worse.

For the sake of those not in the IRC channel last night, merging -U
into -S also makes the organization of pacman's options even weirder.
Querying installed packages would be -Q, querying sync packages -S,
installing sync packages or package files -S, but querying package
files is -Qp.  We can't just merge -Qp functionality into -S because
it includes -Qpl and -Qpc which have no -S counterpart and -Sl and -Sc
already have different meanings.

apg


More information about the pacman-dev mailing list