Feature request: pacman --needed

[Mithrandir2k18]

Hi,

I am using pacapt to be able to have identical dependency install scripts across multiple linux distros. I also use arch, so I installed pacapt as pacman on other distros. Ideally I'd like to do something like this:

pacman -S dependency1 --needed
pacman -S dependency2 --needed

To work with pacapt as well, so I can have concise code that installs dependencies only when necessary. Also an option like --yes would be nice, so that installs don't ask for confirmation.

[icy]

hi @Mithrandir2k18 , I have used that option. If it's supported on different platform it's easy to have the patch.

Is the option --yes optionally required by --needed?

Thanks

[Mithrandir2k18]

@icy Sorry I should have titled the feature request differently. The common idea is to have a smart "omniplattform dependency install script" that won't ask for confirmation.

Now arch's pacman has a --needed flag, it will automatically ignore any packages that are satisfied. Otherwise it will reinstall a package installed with -S that is already present. That feature would be nice to have in pacapt; should be a simple local package search before installing, that is done before each install with the --needed flag provided. Some package managers like apt default to this option, but pacman doesn't. If all non-pacman package managers default to this, simply ignoring this flag so we can keep using it when on arch(and not using pacapt), would work I guess.

A --yes flag (or even better --noconfirm, to stay consistent with pacman), would be amazing for install scripts as well. However I recently learned that one can yes | pacapt -S package which will do the same, but is a little hacky I guess. I'd be really cool to be able to do something like this:

pacapt -S --needed --noconfirm dep1 dep2 dep3

That'll install all listed dependencies, ignore satisfied ones without interrupting and not ask for confirmation; and throw errors as usual if a package cannot be found.

[rami3l]

@Mithrandir2k18 I'm actually rewriting pacapt and I just come across this issue. I'm interested in adding this option, but I wonder if pacapt -S should do a force reinstall (to be more like pacman) or do a --needed install when calling package managers like apt...

[Mithrandir2k18]

@rami3l That's a really good question and seems to be a design choice to make. Since I personally love to use pacapt to emulate pacman on distros that don't come with it, I'd prefer it adhering closely to the way pacman works; so that I can run the same install scripts on all my machines.

That said, whether --needed on ubuntu simply gets accepted, but ignored, since it's the default for apt anyway, or whether omitting --needed on ubuntu causes pacapt to run apt remove packagename; apt install packagename probably should be decided based on why pacman does it and why apt doesn't do it by their defaults. I have no idea why pacman chooses to default to reinstall present packages. Maybe they have a good reason, maybe apt has a better reason.

In short, I'd personally prefer pacapt to behave exactly like pacman, and only divert when it has a very good reason to, and if it doesn't break anything.

[rami3l]

@Mithrandir2k18 Thanks a lot for your reply.

Now I see the need of using a single script across platforms, but it seems that we can ask similar questions about --noconfirm and more…

A nice thing about pacman is that, although -S is both for install and reinstall, there will always be a prompt asking if you really want to (re)install, unless you said --noconfirm.

First I thought, for example, can I add y/N questions to brew install (they do not exist natively, but what if I just want to emulate pacman and to ensure the --noconfirm option works exactly in the same way every time)? But then I realized that almost all package managers differ in the way y/N pops up.

And finally the big question becomes: is this project here to work exactly like pacman?

@icy might agree with me that what we really want is just an automated version of Pacman Rosetta.

PS: But at least, I can ensure that, for example, when you pass --noconfirm, there won’t be any prompt.

[rami3l]

@Mithrandir2k18 Now I've tried to add a custom [Y/n] prompt to homebrew. That can be consistent, since homebrew doesn't have any prompt at all. But then I wonder what will happen when I move on to apt/dpkg. Some commands will have their native prompt while I have to add my own to some others... Things will get quite messy there, and I really doubt if this is the right way of doing things... (?_?)

---

Update:

What's more, I realized that the need of writing a single cross-platform script via pacapt might never be satisfied, because in order to do that, we need to implement #44, which is, obviously, out of the scope of this rather simple project :(

So now I am actually wondering if I should remove this [Y/n] prompt to respect the original implementation of that feature in homebrew... Still not quite sure.

[Mithrandir2k18]

@rami3l If maintaining it for your project is too much work you could add an option to pass a mapping file, so e.g. if I need an apache server and the package is named X on pacman and Y on apt, I can provide a file that does the mapping based on OS. This way a user can maintain the mappings they need themselves, and if they are nice they can share it via pull requests.

I also don't know if artificially adding prompts to package managers that don't have them is the right thing to do. As I personally am mostly using pacapt for scripts, I'll always add --noconfirm anyway, meaning the prompts won't show either way when I use it. If I were to plan this feature into a project, I'd push it to the very back and do it last, or when specifically requested.

[rami3l]

@Mithrandir2k18 This idea sounds interesting! Might look into it later. Thanks a lot! 😆

PS: After some tweaks I think I am OK with additional prompts added to homebrew (useful when preventing unwanted “big” operations eg. installation), but since some might not like it, an rc file would definitely help!