Choco: Prevent redundant recreation of Start Menu shortcuts

[eyalroz]

Many people organize their Start Menu shortcuts, rather than just leave them in their original locations. For example - shortcuts can be placed in a Categorial hierarchy, with some removed altogether.

Now, if you update a chocolatey package, after its initial installation - it will re-create the Start Menu shortcuts in the same locations it first created them, even though it is more likely than not that if they're missing, it is due to intentional moving or deletion.

I'm not sure whether it is the packages themselves which install the shortcuts, or choco.exe; but it is a general issue rather than an issue with some package.

I suggest that Start Menu shortcuts be recreated when updating a package version...

• Never, with an option to always recreate them; or
• Always, but with an option to never recreate them; or
• Only for shortcuts which are new to the update; or
• With a prompt/dialog regarding reinstallation of missing shortcuts.

One could also consider the possibility of tracking shortcuts' location within the Start Menu, but perhaps that's excessive.

[FreeMinded]

If the package allows you to select if a shortcut is created or not upon installation, the useRememberedArgumentsForUpgrades will solve your issue. See
https://chocolatey.org/docs/chocolatey-configuration

Else the package might need improvement to better handle the shortcut creation.

[eyalroz]

@FreeMinded : Well, so far, as a user, I have generally not been asked to provide any configuration options (either that or I'm being senile here). Regardless, suppose that I was asked whether or not to add a shortcut. The option you mentioned is really not relevant - because I would want the _opposite_ value remember, and only for this option, i.e. if shortcuts were created, I want them not to be created again.

Also, this is not something to be left to the individual packages - it is a common issue and it is unreasonable to go chase each app and make sure it does something smart about its shortcuts. It is a matter for choco(latey) to take responsibility for. IMHO.

[FreeMinded]

@eyalroz you will not be asked, but you can tell chocolatey (only if the package supports it) to or not to create shortcuts. There are many different types of packages. Some examples:

• the Adobe Reader package by default does not create a desktop shortcut. If you want one, install it with choco install adobereader -params '"/DesktopIcon"'. (The installer default is to create one.)
• in the upcoming Firefox packages you will be install without desktop shortcut with choco install Firefox --params "/NoTaskbarShortcut /NoDesktopShortcut" (The installer default is to create one.)
• the Airtame Installer does not have a switch to decide about shortcut or not, but the package has implemented a workaround and will remove the shortcut if you install with choco install airtame -params "/RemoveDesktopIcons"
• Other packages have neither of above and will just do what the original software installer does.

The option useRememberedArgumentsForUpgrades will remember those arguments for you. So you don't end up with unwanted shortcuts after upgrades (for packages supporting it).

I don't think there is a good way to solve this on a chocolatey level. The software installers are just too heterogeneous on what and how they do it. IMHO

[eyalroz]

@FreeMinded : What percentage of packages allow for such a parameter? And - does each one have its own separate parameter? Can I get those all listed together, somehow?

[pauby]

@eyalroz Chocolatey manages the packages that are installed. Those packages can be software (typically) but can be anything really that can be wrapped into a package (licenses, registry changes etc.).

Software on Windows can have their shortcuts installed by the installer itself (i.e. the EXE or the MSI may just place shortcuts where it wants to as that's part of its installation routine). Sometimes this can be changed with switches to the installer (i.e. /NoDesktopShortcut, /NoShortcut, /NoIcons etc.). You can sometimes pass those switches through to the installer from Chocolatey using choco install mypackage --installargs="'/NoIcons'".

Sometimes the package maintainer exposes these parameters through the package and, as an example, if they offered a /NoIcons package parameter you would use choco install mypackage --params="'/NoIcons'".

One thing that's important to understand is that Chocolatey manages packages. Packages manage installers. Chocolatey does not manage installers.

So as an example, taking Google Chrome. Chocolatey manages the Google Chrome package (install, upgrade, uninstall etc.). The Google Chrome Package manages the Google Chrome installer (so it will provide the data to run the installer to install the software, uninstall the software, pass switches etc.).

So when it comes to things like shortcuts, that's an installer thing and that installer thing is managed by the package.

Now I get that it's frustrating when there is so much disparity out there with regard to some packages exposing the parameters and some not doing so. But it is down the maintainers. So it's best to report it directly to them.

I hope that helps.

[eyalroz]

@pauby : I understand chocolatey doesn't manage installed package per se. But it could:

1. Allow the user to set a single option ("I don't want shortcuts installed" or "I don't want shortcuts installed on update"), and then pass the appropriate option - if possible - to the installer. And the people submitting packages to the chocolatey repository will (need/be able) to specify what that option is for their installers.
2. For the packages which don't support this option - note which shortcuts the installer has created, and delete them (silently/with a prompt).

Now, (2.) is more far-reaching, but I don't see why (1.) is such a big deal.

[pauby]

@eyalroz I appreciate what you are saying around 1 but again, to stress the point, the installer is the responsibility of the package to manage, not Chocolatey. I'm not being awkward when I'm saying that, it's one of the fundamentals of Chocolatey and any package manager.

But to take your point and look at it a bit more closely, Chocolatey could allow a feature / switch to say 'hey don't install shortcuts'. That's not a big deal as you said. It's just a switch. How it would actually stop the shortcuts is a big deal. If it was implemented, what does Chocolatey tell the package / installer?

Chocolatey could pass a defined switch onto the installer.

There are a large number of installer types. Assuming those installer types all use the same switch to prevent shortcuts, then Chocolatey could pass that switch to the installer each time (once it's worked out what type of installer it is).

Unfortunately that's a nirvana that doesn't exist. Every installer is different. Two bits of software using the same installer can implement it in different ways, using a different switch, or not implement it at all. So Chocolatey has no idea what switch would need to be passed to an installer to stop shortcuts from being created. So this is really useful for us.

Packages could add a package parameter to stop shortcuts if the installer supported it

If the installer supports not creating icons, and the package exposes that to the end user using a package parameter, then again Chocolatey won't know this as it's down to the package to decide that if they allow shortcuts to be created and how they want to create them. So this isn't really of any use to us.

Enforce Chocolatey Helpers

There is a Chocolatey helper, Install-ChocolateyShortcut, and if the switch to 'not create shortcuts' was passed to Chocolatey, when that function is used it could simply not create the shortcut. That's a solution but what if that function isn't used? What if the shortcuts it's creating are necessary for functioning of the software (and not just a useless desktop shortcut)? That would impact the functionality of the software and the usefulness of the package.

It would also have to be used by the package maintainer. This may be useful to us but, if it were to be enforced at package submission something would need to be created to automatically check for that and apply it. At the point of moderation the moderators would have to also look for it being used. That's a huge amount of work for something, which I'd suggest, is little gain for the vast majority of people and a task which is supposed to be the responsibility of the maintainer.

Package / Maintainer Responsibility

So to come back to what I said before, it's not Chocolatey's job to manage the shortcuts. Shortcuts are a software / installer 'thing'. It's the packages job and by relationship the maintainers job. The package / maintainer knows about the software (and therefore what shortcuts it creates) and can craft that package accordingly. Chocolatey doesn't have this information.

If the installer supports not creating desktop shortcuts (and I'd suggest not many of them do) then the package can expose that as a package parameter. If that's not being done then the best course of action is to contact the maintainer and ask them to do that.

[eyalroz]

@pauby : I agree that bottom-line responsibility reasonably lies with the package maintainers'. But chocolatey could make some effort in that direction without guaranteeing results. Let me refine my earlier taxonomy:

1. If the package has specified (in the metadata chocolatey reads) how to tell it not to add shortcuts, chocolatey will do so when the chocolatey option I mentioned is enabled.
2. An initial request email of all package maintainers to add that information to the meta-data, and to enable non-generation of shortcuts entirely and/or on update.
3. Chocolatey contributors make a one-time sweep of some/many popular packages to add that piece of meta-data for them, even if package maintainers have not obliged.
4. A periodic notification email to package maintainers of this information missing from the package meta-data. <- Perhaps you already have something like this about other package issues,, e.g. no new/newly-verified version for X years.
5. The shortcut deletion option.

Only (5.) takes bottom-line responsibility. The other options are just helping this along without individual users having to check individual options of many packages and write many emails to many maintainers.

[ferventcoder]

@eyalroz a couple of related issues - #4 #344

[eyalroz]

@ferventcoder : Thanks. I've added some comments there explaining how the three issues relate.