[pacman-dev] [PATCH RFC] DWIM if user attempts to sync on a file
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
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
---
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. Allan
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
---
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
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
---
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. For reference, you can see how pacinstall distinguishes the two here: https://github.com/andrewgregory/pacutils/blob/master/doc/pactrans.pod apg
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
---
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: 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). Andrew
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
---
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
On Fri, Jun 17, 2016 at 11:21:08AM -0400, Andrew Gregory wrote:
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.
Perhaps consider requiring an absolute path for distinguishing local files. It might also be possible to re-use the -f flag (such as tar(1)) for being extra explicit.
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... Allan
On Thu, Jun 23, 2016 at 10:29:20AM +1000, 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 hopefully just `pacman -U ./glibc-2.23-5-x86_64.pkg.tar.xz`, but see below...
or is providing a full path enough? I don't think we allow "/" in package names...
makepkg doesn't, but pacman does. $ sudo pacman -U cower-16-1-x86_64.pkg.tar.gz loading packages... resolving dependencies... looking for conflicting packages... Package (1) New Version Net Change cow/er 16-1 0.12 MiB Total Installed Size: 0.12 MiB :: Proceed with installation? [Y/n] d
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?
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? IMO we really ought to sync the sanity checking behavior of pacman with that of makepkg. d
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
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
participants (6)
-
Allan McRae
-
Andrew
-
Andrew Eikum
-
Andrew Gregory
-
Dave Reisner
-
Earnestly