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