Chocolatey-coreteampackages: (alldup) automatically runs post install

[bcurran3]

RE: https://chocolatey.org/packages/alldup/4.1.5

Expected Behavior

For a program package to install and the program to NOT run until I tell it to!

Current Behavior

Installation of AllDup results in the program running post installation.

Possible Solution

Consider using Start-CheckandStop in https://chocolatey.org/packages/chocolatey-misc-helpers.extension

Steps to Reproduce (for bugs)

Fresh install of https://chocolatey.org/packages/alldup/4.1.5

Context

I expect all Chocolatey program packages to silently install and not run post install.

Your Environment

Windows 10
Chocolatey v0.10.11
https://chocolatey.org/packages/alldup/4.1.5

[bcurran3]

https://chocolatey.org/packages/alldup/4.1.5.20180730

Exhibits the same behavior.

If you don't like my extension, just add:
Get-Process "AllDup" -ErrorAction SilentlyContinue | Stop-Process
at the end of your chocolateyInstall.ps1

[majkinetor]

It has to be more complicatwd than that to account for slow machine.

[bcurran3]

Then:
Start-Sleep 10
Get-Process "AllDup" -ErrorAction SilentlyContinue | Stop-Process

Reality is: it runs now on slow machines and fast machines. Simply by adding it even without the Start-Sleep delay will accomplish the goal on SOME machines. Mine are fast. :)

The method via the function in my extension WAITS 5 minutes for it, so it might be the best solution for you @majkinetor. :)

[majkinetor]

That is still inadequate. Hard-coding sleep values are anti-pattern and we don't want to promote it here. We don't replace something that sucks with something that sucks less, in general.

You need to wait with timeout, not wait hard coded value.

Something like; while (!$timeout -and ! ps alldup ....) { sleep 1 ...} else { kill aldup -ea 0 }

[bcurran3]

Sucks less > Sucks a lot.

Wait with timeout has already been my suggestion since step #1 of opening the issue, please re-read above. Since there's been no forward movement and I figured maybe the core team thought it "beneath them" to use an extension that I made, I suggest an alternative.

I don't care about the method. I just want the program not sitting around on my screen after install/upgrade. Doesn't seem appropriate for a chocolatey coreteam package. Pick a method, run with it. If you want me to do a PR, I'll fix it my way.

[majkinetor]

maybe the core team thought it "beneath them" to use an extension that I made, I suggest an alternative.

We do not use anything not belonging in this repo as we can't control it.

Sucks less > Sucks a lot.

I agree about this specific case, but I don't think you count all elements in the "fixing cost". This repository is important and we do not want to promote any type of fix/coding because people can choose any package here as a template.

Since there's been no forward movement

That outcome doesn't mean we don't think this is necessary, we clearly do as shown by labels. I relabeled this as a bug as non-services shouldn't start after installation.

I don't care about the method. I just want the program not sitting around on my screen after install/upgrade. Doesn't seem appropriate for a chocolatey coreteam package. Pick a method, run with it. If you want me to do a PR, I'll fix it my way.

So we have different goals. I (and I think all of us) care about the method and explained already what needs to be done. Feel free to do a PR, if not, we will probably get to it one way or another.

This package need to get improved in general - missing license, eventual embedding etc. It also has a portable version which IMO makes more sense to make as it wont start on its own. Perhaps even contacting an author for the setup option not to launch (or if it exists finding it).

[bcurran3]

Now we're speaking the same language.

[majkinetor]

I contacted them via site form asking for redistribution rights.

[AdmiringWorm]

@majkinetor said:
We do not use anything not belonging in this repo as we can't control it.

That's not entirely true, we actually use a chocolatey extension in a few KB packages that is developed in a different repository.
Namely the chocolatey-windowsupdate.extension.

With that said though, we rarely use extensions and code that isn't already available in this repository.

[majkinetor]

Right, that must be the only one we use now but its scope is very limited.

BTW, I got response from alldup author allowing redistribution. I am attaching the PDF of the mail here if anybody wants to start working on embedding procedure (if not, I will probably do it when I get some free time).

Redistribution.pdf

[bcurran3]

BTW, I got response from alldup author allowing redistribution. I am attaching the PDF of the mail here if anybody wants to start working on embedding procedure (if not, I will probably do it when I get some free time).

Good deal.

What did he say about a switch to make it NOT run after install?

[majkinetor]

Nothing, but if the switch exists it will be easy to find, and now that we can embed portable variant its less relevant.

[bcurran3]

Embedded = good.
Embedded does not make the program running after install less relevant, without an install switch to not run post install, the same problem exists. I'm hoping I'm wasting my finger's time and that you are already in agreement about killing the task post install no matter what method you choose to do so.

[majkinetor]

No it doesn't, but embedded portable does, since there is no installer, and no switch.

[bcurran3]

Would this be acceptable?:
# waits for up to 5 minutes to kill alldup post install

$LoopMePlease=1
Do {
    Start-Sleep 5
    if((Get-Process "alldup" -ea SilentlyContinue) -eq $Null){ 
      } else { 
        Stop-Process -ProcessName "alldup" -Force
        break
       }    
    $LoopMePlease++
   }
Until ($LoopMePlease -gt 60)
}

5 minutes might be excessive in this case, a lower time/loop amount might be better in case the end user quits the program on his/her own. 1 minute? 2 minutes?

[majkinetor]

This should be embedded now that we have redist rights. When doing so just use portable version and this problem disappears.

[bcurran3]

Agreed. Portable solves my issue.

[bcurran3]

I haven't seen (or looked for) the portable package. I'm hoping that it doesn't create an issue of a GUI program without an icon to launch it. :)

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[bcurran3]

relevant

[bcurran3]

AllDup 4.4.0 still launches after upgrade (and assumed install).