flashplayer* packages are not installing for FOSS users

[pauby]

Packages are downloading end-of-life-alternatives.html instead of the binaries.

flashplayerplugin:

flashplayerpapi:

I'm assuming flashplayeractivex is also affected.

Note that these work for the business editions (using the CDN). flashplayerplugin:

flashplayerppapi:

This doesn't work for FOSS users and should we be more explicit in the packages (releasing a final version).

[TheCakeIsNaOH]

This doesn't work for FOSS users and should we be more explicit in the packages (releasing a final version).

Releasing a final version would presumably break the package for business users as well, as then there is no longer a valid installer to cache.

I'd suggest simply unlisting the packages, as per the guidance I'd give any maintainer in this situation.

[pauby]

If we unlist the packages then licensed users can no longer install them in the normal way.

Releasing a final version would presumably break the package for business users as well, as then there is no longer a valid installer to cache.

That's a good point.

[TheCakeIsNaOH]

If we unlist the packages then licensed users can no longer install them in the normal way.

Right, but this is the chocolatey-community maintainers, where the intention is community packages for the community, so I don't think having a support burden of continuing to list a package that is broken for non-licensed users is appropriate. Support burden as in there would be the occasional issue/discussion/comment about these packages being broken from community members.

[pauby]

Right, but this is the chocolatey-community maintainers, where the intention is community packages for the community,

The Chocolatey Packages Chocolatey Community repository has always been a community of people maintaining packages that ultimately end up in the Chocolatey Community Repository. So the community aspect is of people.

The description of the repository is:

Chocolatey Community Maintainers Team Packages - packages that are managed and maintained by core community team for community package repository

It doesn't state, nor was it ever the intention, that the packages in this repository would only be maintained for community users use (i.e. FOSS). The Chocolatey Community Repository, which as the description states is where the packages end up, is for everybody, the many, not the few. There are recommendations for organizations (licensed and not) and there are licensed users who are part of the community (Professional licensed users, for example).

so I don't think having a support burden of continuing to list a package that is broken for non-licensed users is appropriate

That language used here is loaded and exaggerated in my opinion, which I don't think is helpful. If you would rather not support those packages, you can do that. There are no expectations here.

If the community team feels that the packages should not reside in this repository, then we can raise an RFM request. Alternatively, I will pick the package up. However, the links to this repository will still be in place, as no new version will be released. But it is an option.

Support burden as in there would be the occasional issue/discussion/comment about these packages being broken from community members.

I would suggest no more than any other package. There are ways we can mitigate this by pinning an issue and Disqus comment. Not perfect, and requires people to read them, but is an option.

[AdmiringWorm]

What we have done in the past when a software went away, and it was cached on the CDN for the community repository was to just leave it as is.
Keep it listed, move the package to the manual directory, and in some cases a Disqus comment would be added, but usually only when users asked questions about it.

The only time packages would get unlisted was when the download location went away, and there was no cached version on the CDN.
A final release was never created in these cases.

[TheCakeIsNaOH]

That language used here is loaded and exaggerated in my opinion, which I don't think is helpful.

Yes, I could have worded that better. We appear to have different contexts around that phrase.

I would suggest no more than any other package.

I think we will have to agree to disagree on this one.