[pacman-dev] Bad error message on invalid pacman -S operation
I did "pacman -S" today instead of "pacman -U", and I noticed the error message is not all that great, and I think this is a regression: dmcgee@galway ~/projects/arch-repos/valgrind/trunk $ pacS /home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz Password: error: repository '' not found error: '/home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
Dan McGee wrote:
I did "pacman -S" today instead of "pacman -U", and I noticed the error message is not all that great, and I think this is a regression:
dmcgee@galway ~/projects/arch-repos/valgrind/trunk $ pacS /home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz Password: error: repository '' not found error: '/home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
Definitely a regression:
pacman -S sed-4.2-1-i686.pkg.tar.gz sed-4.2-1-i686.pkg.tar.gz package not found, searching for group... error: 'sed-4.2-1-i686.pkg.tar.gz': not found in sync db
But... why is it thinking the file name is a repository? And what about the '' repoisitory not found. That is really weird. Allan
On Fri, May 1, 2009 at 9:07 PM, Allan McRae <allan@archlinux.org> wrote:
Dan McGee wrote:
I did "pacman -S" today instead of "pacman -U", and I noticed the error message is not all that great, and I think this is a regression:
dmcgee@galway ~/projects/arch-repos/valgrind/trunk $ pacS /home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz Password: error: repository '' not found error: '/home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
Definitely a regression:
pacman -S sed-4.2-1-i686.pkg.tar.gz sed-4.2-1-i686.pkg.tar.gz package not found, searching for group... error: 'sed-4.2-1-i686.pkg.tar.gz': not found in sync db
But... why is it thinking the file name is a repository? And what about the '' repoisitory not found. That is really weird.
It is our parsing code. Note the three cases- direct file, relative path, and absolute path: dmcgee@galway /home/makepkg/packages $ pacS valgrind-3.4.1-1-x86_64.pkg.tar.gz valgrind-3.4.1-1-x86_64.pkg.tar.gz package not found, searching for group... error: 'valgrind-3.4.1-1-x86_64.pkg.tar.gz': not found in sync db dmcgee@galway /home/makepkg/packages $ pacS ../valgrind-3.4.1-1-x86_64.pkg.tar.gz error: repository '..' not found error: '../valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository dmcgee@galway /home/makepkg/packages $ pacS /home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz error: repository '' not found error: '/home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository I'm not sure what the "fix" is, but it definitely is odd behavior. -Dan
Dan McGee wrote:
On Fri, May 1, 2009 at 9:07 PM, Allan McRae <allan@archlinux.org> wrote:
Dan McGee wrote:
I did "pacman -S" today instead of "pacman -U", and I noticed the error message is not all that great, and I think this is a regression:
dmcgee@galway ~/projects/arch-repos/valgrind/trunk $ pacS /home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz Password: error: repository '' not found error: '/home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
Definitely a regression:
pacman -S sed-4.2-1-i686.pkg.tar.gz
sed-4.2-1-i686.pkg.tar.gz package not found, searching for group... error: 'sed-4.2-1-i686.pkg.tar.gz': not found in sync db
But... why is it thinking the file name is a repository? And what about the '' repoisitory not found. That is really weird.
It is our parsing code. Note the three cases- direct file, relative path, and absolute path:
dmcgee@galway /home/makepkg/packages $ pacS valgrind-3.4.1-1-x86_64.pkg.tar.gz valgrind-3.4.1-1-x86_64.pkg.tar.gz package not found, searching for group... error: 'valgrind-3.4.1-1-x86_64.pkg.tar.gz': not found in sync db
dmcgee@galway /home/makepkg/packages $ pacS ../valgrind-3.4.1-1-x86_64.pkg.tar.gz error: repository '..' not found error: '../valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
dmcgee@galway /home/makepkg/packages $ pacS /home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz error: repository '' not found error: '/home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
I'm not sure what the "fix" is, but it definitely is odd behavior.
I suppose we could catch the leading "/" or ".."? I can't think of a case where they would be right. Allan
dmcgee@galway /home/makepkg/packages $ pacS ../valgrind-3.4.1-1-x86_64.pkg.tar.gz error: repository '..' not found error: '../valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
Wow, this is ugly. The problem with PM_ERR_PKG_REPO_NOT_FOUND error code, that it needs a param (which repo was not found? this info is an alpm internal), that is impossible with error codes. Imho we should remove this error code [the "repository 'foo' not found" message is printed via alpm_log()], and just use PM_ERR_PKG_NOT_FOUND instead.
dmcgee@galway /home/makepkg/packages $ pacS /home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz error: repository '' not found error: '/home/makepkg/packages/valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
I'm not sure what the "fix" is, but it definitely is odd behavior.
I suppose we could catch the leading "/" or ".."? I can't think of a case where they would be right.
Allan
To the original problem: After all PKG_NOT_FOUND errors (assuming REPO_NOT_FOUND was removed) we could do access(target, ...) in the front-end; and if found, print a "Did you mean -U?" message. Of course, this is not a perfect solution (user typo?), but I have no better idea... Bye
dmcgee@galway /home/makepkg/packages $ pacS ../valgrind-3.4.1-1-x86_64.pkg.tar.gz error: repository '..' not found error: '../valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
Wow, this is ugly. The problem with PM_ERR_PKG_REPO_NOT_FOUND error code, that it needs a param (which repo was not found? this info is an alpm internal), that is impossible with error codes. Imho we should remove this error code [the "repository 'foo' not found" message is printed via alpm_log()], and just use PM_ERR_PKG_NOT_FOUND instead.
I've just now realised that this is the reason for the fact that in this case we don't start to find a group. (We fallback to search_group, iff alpm returns with PKG_NOT_FOUND.) So I am a bit unsure now, this behaviour is better, because the group-name cannot contain '/' (off-topic: however, repo/group can make sense, but that is not implemented atm). Then we should just rephrase PM_ERR_PKG_REPO_NOT_FOUND in alpm_strerror().
participants (3)
-
Allan McRae
-
Dan McGee
-
Nagy Gabor