FS#48835 - add a --yes flag to pacman
Attached to Project:
Pacman
Opened by msrd0 (msrd0) - Thursday, 07 April 2016, 17:39 GMT
Last edited by Allan McRae (Allan) - Thursday, 15 December 2022, 06:20 GMT
Opened by msrd0 (msrd0) - Thursday, 07 April 2016, 17:39 GMT
Last edited by Allan McRae (Allan) - Thursday, 15 December 2022, 06:20 GMT
|
Details
I just wanted to use pacman from a script that tried to
install some self-build packages. The problem is that
those
packages conflicted and provided, but not replaced, some already installed packages. I passed --noconfirm to pacman but this triggered the default option to be used, what in this case was no. Since I saw no way to assume yes on this option (I couldn't do yes | pacman because it said y is not a valid member of the available libgl packages) I looked into the pacman source code and added a --yes flag that works together with the --noconfirm option to assume yes on all options and not only on those that specify yes as their default. I attached a patch that works quite well for me. |
This task depends upon
Closed by Allan McRae (Allan)
Thursday, 15 December 2022, 06:20 GMT
Reason for closing: Won't implement
Thursday, 15 December 2022, 06:20 GMT
Reason for closing: Won't implement
If there is a need for it, I could add an aur package with that patch applied, though I would prefer merging this into pacman source code.
What technical reasons do you have for refusing to merge this patch? "Doesn't affect me" is not a good answer...
It's impossible to know beforehand which packages conflict when building packages in a container with `makepkg`, and creating a new `Dockerfile` for every new build is not feasible. This is especially apparent when building multilib packages.
That's false, first question is `N` by default, second question is `Y`. Had this exact issue 1.5 years ago, and the stdin hack works extremely badly. Ended up migrating to using `find` instead:
https://github.com/nfnty/dockerfiles/issues/2
The default answer for cleaning the cache is only no if you pass --clean twice. In that case, why does `yes | pacman -Scc` "work extremely badly"?
What's the alternative? As @nfnty said that it doesn't make sense to make a new dockerfile for every build. I was writing that patch as I was trying to build some packages using chroot (makechrootpkg) where I simply had a package A depending on B and replacing some C which itself was required by a library required by B ... and makechrootpkg simply installed package B and then A and failed.
I currently see no problems for people like @andrewgregory who don't see any use in this patch. You don't need to use it. But it will make life easier for people like me or @nfnty.
Because using `yes` is a stupid hack that does not work reliably, especially when there's no TTY.
Please, present a single valid technical reason for why including this functionality would be negative.
The only thing I don't see as well is any reason for not applying my patch.
I'm not entirely sure that I understand what you're doing. Perhaps if I understood your use case better we could come up with a solution less likely to lead to people shoot themselves in the foot.
I would still like to know when `yes | pacman -Scc` would fail. I'm not sure why a TTY or lack of one would affect that.
Once again I was trying to install some .pkg.tar packages to a makechrootpkg and had issues because they weren't installed at the same time but one after another. I switched to docker and ubuntu and I'm now building the packages on travis so the patch isn't so much important to me anymore. But still pacman should provide a way to do this. Maybe it would also help to edit the makechrootpkg script to handle those packages in a way that they are all installed at the same time. This would also be a nice thing because then one could have circular dependencies installed, though I never needed that feature.
Another thing that would be nice is to have a switch to assume yes on questions 'replace bla with bla'. Since I'm sometimes experiencing ext4-errors while updating my system (I believe they are related to my ssd), pacman always has a broken file database and needs some packages to be force-installed. And it is really annoying to press y all the time after you once checked all the changes. But in theory, most of the time I should be able to use the `yes | pacman` option here, and I guess that this is a very unique use case.
I didn't think to mention this earlier, but there is an undocumented --ask option that can be used to reverse the default (more accurately, it reverses the answer) for individual prompts. It exists solely for our test suite, so I make no guarantees that it won't change in the future without warning, but it can be used to accomplish what you want if we can't come up with something better.
I is about a year ago I wrote that patch so I can't provide with the exact use case I had back then. But I can remember that I patched pacman and edited makechrootpkg to add the --yes flag to pacman to solve that issue. Back then I wasn't able to find another solution and my post into arch linux forum (that was moved without justification into topics going nowhere so didn't got much attention) didn't reveal any better solution.
But keep in mind that a few people are actually interested in a --yes flag. Not only on this request but also in github issues and on unix stackexchange. And other popular distributions like debian include such flags and I guess that there were good reasons on those distros to include such a flag.
Until somebody interested in this option gives me a compelling justification without a better alternative, I will continue to be against this change.
Containers are great because they're layered. You have a known good base image such as `nfnty/arch-devel` and build on top of that, as can be seen here: https://github.com/nfnty/dockerfiles/blob/master/images/arch-builder/latest/Dockerfile
It's currently impossible to create a new layer on top of an image with conflicts. `yes | sudo pacman --sync --noconfirm lib32-clang` does not work at all when `gcc` is installed due to a conflict with `gcc-multilib`. It shouldn't be needed to create a whole new stack just because pacman thinks that everyone is using it interactively.
Of course `yes | pacman --noconfirm` doesn't work. --noconfirm prevents the prompt from ever being issued, so the `yes` is completely useless. If you remove the --noconfirm it works just fine. You could also use pacinstall: `pacinstall --no-confirm lib32-clang --remove gcc`.
Which is exactly my point. `yes` doesn't work reliably.
`makepkg` has absolutely no way of knowing how to solve conflict problems. This patch would make that possible.
All your last example did was demonstrate a misuse of `yes` with --noconfirm. That doesn't mean that `yes` is unreliable; everything is unreliable if you misuse it.
What are you doing with makepkg that it's non-interactive and none of the aforementioned solutions work?
But I don't see a justification for saying "we don't need to implement in pacman because program xyz (itc pacinstall) can do it already". In fact pacinstall is not preinstalled and such needs to be installed which may result in conflicts. If pacman becomes an incomplete tool that refers to other tools in cases where it fails I'd stop using it.
Again I'm using apt-get -yy in container builds a lot and never had any problems with it. Huge systems like travis rely on the existence of such flags. It is realy sad that ArchLinux/pacman is not useable in those cases.
The --force flag might be misused a few times but is essential. Apart from my problem with broken databases because of an unreliable ssd there are many python packages that have a cache inside the package that gets modified by pip. Without the --force flag I wouldn't be able to install most of the python packages.
I got one last idea to prevent misuse of the --yes option. How about an option in /etc/pacman.conf that explicitly needs to be set in to make pacman accept --noconfirm --yes? This would hugely reduce the misuse of the flag but would still enable the use in containers. And I still don't see a reason why --yes in containers might be a misuse.
Admittedly this works with piping `yes` to it.
But I'm not sure I understand why this is so open to abuse. As I understand it, the reason we deprecated and removed --force is due to it being a blunt ax that mutilates your package database and does unsafe, risky, and downright incorrect things to your system and doesn't even offer you granularity over how you do it. Whereas a --yes flag just assumes a noninteractive environment and optimistically attempts to approve every *policy* it can.
Thanks for the trick with --ask it solved my problem :D
Sometimes I get the following question when I install updates with pacman (Note: I have never encounter this question, there the solution wasn't to answer 'yes', but maybe someone has)
> warning: removing 'opencolorio' from target list because it conflicts with 'opencolorio1'
> :: opencolorio1 and opencolorio are in conflict. Remove opencolorio? [y/N]
but thanks to the information I found about --ask here:
https://bbs.archlinux.org/viewtopic.php?pid=270866#p270866
I could make pacman answer yes to the question with the following command:
sudo pacman -Syu --noconfirm --ask=4
I hope someone else (or future me) will find this useful :D