Arch Linux

Any updates on this issue?

Same question. For example because of lack of that functionality it is hard to automate Arch setup using Ansible for example. Look: https://github.com/pigmonkey/spark/issues/36

Because of no reaction of the developers of pacman I started to package for debian and using docker to install and run everything. Works fine in my case.

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.

I have little desire to make it any easier to automate responses to pacman's questions. Either use `yes | pacman` or give pacman enough information upfront that it doesn't need to ask the questions.

That makes no sense. This patch is extremely small and would make the lives easier for everyone using containers. Using `yes | pacman` is an ugly hack that breaks way too often and it's very hard to predict when pacman will ask an interactive question. Currently it's impossible to automate tasks such as clearing the cache or replacing installed packages.

What technical reasons do you have for refusing to merge this patch? "Doesn't affect me" is not a good answer...

If you know ahead of time what issues will arise that would cause pacman to ask a question, you should deal with the issue directly instead of trying to automate a response. If you don't know what issues will arise, you shouldn't be blindly answering 'yes' to questions in the hope that it will do the right thing. Why is it impossible automate clearing the cache? The default response to both questions is yes, so --noconfirm already works for that. For replacing installed packages you can either remove the old package beforehand, or use pacinstall from pacutils which will allow you to install and remove packages in the same transaction.

There's never a situation where you'd "blindly" answer `yes` to a question. It's always done when all other options have been exhausted.

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

I do not follow. If you don't know beforehand which packages will conflict, how is answering yes to everything not "blind"?

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"?

OK so you tell us answering yes blindly (and thats of course what its doing) to an automated build inside a container where it doesn't matter if something gets broken by that is awfull.

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.

No, it's not blind at all. You know exactly what packages are in each layer and what packages the `PKGBUILD` needs. You just don't want to have to specify every single conflict package manually in a `Dockerfile` for it to work. It should be handled automatically and dynamically every time a new `PKGBUILD` is passed into the container.

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.

I don't think that it does matter whether you call it blind or not. There are use cases where it is definitely blind and there are use cases where you think you know what you are doing.

The only thing I don't see as well is any reason for not applying my patch.

As a developer, every patch affects me because I'm one of the people who has to maintain it after it gets merged. I also have to look at how a feature will be misused, not just its potential benefit. It may not matter if your container breaks, but countless people write pacman wrappers for these sorts of things on systems where breakage has actual consequences. I don't intend to cripple pacman to protect those people from themselves, but I don't want to make it too easy for them to break things either. As I already said, I am of the strong opinion that issues known of ahead of time should be explicitly dealt with beforehand and prompts for unforeseen issues should not be blindly answered. So, any patch that sets out to circumvent pacman's prompts is going to need a strong justification to get an approval from me.

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.

My problem with the `yes | pacman` (not to clear the cache but to install packages) is that it will answer yes to questions like "which package providing libgl do you want to install?", where I prefer to use pacman's default answer than 'yes' which is simply not valid.

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.

You're going to have to fill in some more gaps for me. What's not clear to me is why you can't simply include the provider you want in the initial invocation and why you have to install packages in this piecemeal fashion instead of installing exactly what you want to start with. I understand that you're installing and building packages in a container, but I'm still not sure where in that process the pacman call is happening that you want to use --yes with.

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.

As I mentioned earlier because of the limitations of pacman I used ubuntu on docker instead of arch while arch is still running on the host. Apart from those limitations it is also more convenient with travis.

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.

I told you in that forum thread to submit the patch to pacman-dev if you wanted it to be reviewed, but I don't recall ever seeing it there.

Until somebody interested in this option gives me a compelling justification without a better alternative, I will continue to be against this change.

I still can't understand how you think that using `yes` is a better alternative than providing a native `--yes` option. Your argument goes completely against the Arch philosophy of "user centrality" and "versatility". And if you don't like the name `--yes` then just name it `--force-yes` so that people understand that it may break their systems if they use it.

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.

I prefer `yes` because I don't want to add an option to pacman that is more likely to be misused than it is to be used appropriately. I don't know how much more clearly I can state that.

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`.

How would an option called `--force-yes` be misused? That is like saying that everyone that has ever used `--force` is misusing pacman and should just do everything manually instead. Seriously, stop trying to hold everyone's hands and just give us the power we want.

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.

--force is a great example of an option that gets frequently misused. There's a reason we removed the short form of the option and have actually brought up removing it altogether in the past. I do not consider this a good solution and will not support its inclusion without a compelling justification. Thus far every use case you have given appears to be trivially solved by using `yes`, explicitly installing all necessary packages, using pacinstall (which is specifically intended to be more script-friendly than pacman), or skipping pacman altogether and just using find.

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?

Indeed the patch never appeared on the mailing list because 1. I hate the concept of mailing lists and 2. I've lost interest in this patch because apt does exactly what I needed in my container.

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.

I would also find this useful in makechrootpkg, which currently has the ability to pacman -U --noconfirm -- "${packages[@]}" into a chroot, but fails to accomplish anything useful when the package conflicts with a base/base-devel package (e.g. -git versions).

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.

Hey Andrew Gregory (andrewgregory)

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