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

[Andrew Gregory]

On 06/23/16 at 07:16am, Dave Reisner wrote:
> On Thu, Jun 23, 2016 at 11:41:12AM +0100, Earnestly via pacman-dev wrote:
> > > makepkg doesn't, but pacman does.
> > 
> > Does pacman then disallow forward slashes in repository names?
> > 
> >     pacman -S core/glibc
> > 
> > Is there a great deal of reason to allow slashes in package names when
> > it can't be easily represented in the filesystem without escaping
> > mechanisms?
> 
> No, just the matter of pacman not upholding the same rules as makepkg
> because we assume all packages installed by pacman are created by
> makepkg. It's lazy programming.
> 
> FWIW, this package takes some additional effort to install (one must
> create /var/lib/pacman/local/co), and then there's some odd behavior
> when trying to query/remove it.
> 
>   # pacman -R co/wer
>   error: invalid name for database entry 'co'
>   error: target not found: co/wer
> 
>   # pacman -R local/co/wer
>   error: invalid name for database entry 'co'
>   error: target not found: co/wer
> 
> Why is local/co/cower being parsed as repo 'co' when local/pacman-git
> parsed as the local DB?

It's not. The first message is from alpm parsing the local db.  'co'
is missing a version number and so isn't a valid entry.  pacman may
not check specifically for '/' in package names, but it definitely
can't be said to allow them.

> IMO we really ought to sync the sanity checking behavior of pacman with
> that of makepkg.

I don't have a problem with makepkg being more strict than alpm as
long as alpm actually does support the relevant feature, but yes there
are at least a few places where alpm needs to do a better job
validating things.

apg