RFE: `apkg install` option to reinstall

Sometimes it may be useful to make edits to a program and test them locally within an installed package. Some package managers will not reinstall packages that are already installed by default, and will not even explicitly ask the user what they want to do about it and just stop. It might be a good idea to add an option like apkg install --reinstall, which adds the relevant option to the package manager call. Or maybe even allow the user to do something like apkg install -- [pm_specific_options...]?

Yeah that's a good idea, I was thinking about adding --force or similar that would pass various flags to pms to force the package (re)installation.

The question here is what apkg flag(s) would make most sense - it could be single --force flag or it could be --reinstall, --overwrite, etc.

added enhancement label

changed milestone to %v0.5

I guess it comes down to what the intersection of the supported pms' options is. It seems to be kind of all over the place, e.g. pacman immediately asks the user whether they want to reinstall, apt and zypper simply say that there is nothing to do...

mentioned in issue #80

After studying relevant options from various package managers, I think there should be:

• --reinstall flag to force reinstall
• --force flag to allow more dangerous operations (downgrade, erasing, replace files)

deb: apt

--reinstall:

apt-get reinstall $PKG
# or
apt-get --reinstall install $PKG

--force:

       --allow-downgrades
           This is a dangerous option that will cause apt to continue without prompting if it is doing downgrades. It should not be used
           except in very special situations. Using it can potentially destroy your system! Configuration Item:
           APT::Get::allow-downgrades. Introduced in APT 1.1.

rpm: dnf

--reinstall:

dnf reinstall $PKG

--force:

  --allowerasing        allow erasing of installed packages to resolve dependencies

arch: pacman

--reinstall and --force:

      --noconfirm      do not ask for any confirmation

suse: zypper

--reinstall and --force:

-f, --force                 Install even if the item is already installed (reinstall),
                            downgraded or changes vendor or architecture. Default: false

--force (additionally):

    --replacefiles          Install the packages even if they replace files from other,
                            already installed, packages. Default is to treat file conflicts as
                            an error. --download-as-needed disables the fileconflict check.
                            Default: false

Looks pretty good. I would suggest taking great care at having apkg explain that for some package managers, --reinstall also requires --force to be applied. It may look weird to an outsider if not suitably explained.

Let's say I try to run apkg install --reinstall on OpenSUSE, it should fail with a very descriptive message like:

Zypper's reinstall functionality also enables some other potentially dangerous operations.
Because of this, apkg requires specifying `--force` along with `--reinstall` when used with 
Zypper. Please read the apkg documentation for more information.

No, both --reinstall and --force will pass --force to Zypper, but --force will additionally pass --replacefiles to zypper as well.

Both apkg options will a [!] warning in --help explaining they're dangerous.

Ah, sorry, I misunderstood.

Maybe I'm overthinking and overcomplicating it, so take this with a grain of salt and feel free to disregard, but...

What if both --reinstall and --force printed out the resulting command (apkg already does that) and asked the user for a [y/N] confirmation? (Possibly with an additional possible --yes option to just do it.) Just to let them see what exactly is going to happen? My main rationale is that for every backend these options are going to do a slightly different dangerous thing. Unpredictable behaviour is the last thing you want when running things with sudo, I think.

Ah, sorry, I misunderstood.

Problems are often linguistic ;)

I understand your concerns, but apkg ideology is to run non-interactively (without prompts) as it's mainly a CI/automation tool.

Do or don't, nothing in between.

My main rationale is that for every backend these options are going to do a slightly different dangerous thing.

Indeed, thus the options will look like:

  --reinstall          [!] reinstall existing package(s) (WARNING: this passes potentially DANGEROUS flags to package manager)
  --force              [!] force package(s) installation (WARNING: this passes potentially DANGEROUS flags to package manager)

Aside from these fat WARNINGs, no shorhand option (-r, -f) won't be provided to ensure these aren't ever called by accident.

Unpredictable behaviour is the last thing you want when running things with sudo, I think.

Absolutely, however adding a prompt doesn't make it any more predictable, just annoying, trying to shift the responsibility to the user.

Even if the command was shown to the user, it's unlikely (s)he was an expert at package manager flags to a point of predicting problematic behavior.

If this functionality is officially provided, it needs to be predictable and only way to achieve that I'm aware of is to provide thorough tests ensuring the intended behavior.

Given apkg CI runs on large selection of supported distros, proper tests should provide sufficient degree of trust regarding these options.

Your arguments are persuasive. I rest my case :)

changed milestone to %v0.6

This isn't too hard to implement, but very hard to test as it requires different packaging setup for each package manager and options combination.

I don't want to include such dangerous options without proper testing so I'm moving this to %v0.6 as not to delay %v0.5 .