Chocolatey-coreteampackages: (gnupg) Not approved

[majkinetor]

https://chocolatey.org/packages/gnupg

gep13 (reviewer) on 26 Aug 2019 06:48:15 +00:00:
Is this a duplicate of this package:

• https://chocolatey.org/packages/gnupg-modern

Or is that package going to be getting deprecated?

Its mentioned in Notes

• Versions 2.1.16 to 2.2.12 of this tool are availalbe as gnupg-modern package (non embedded)

The PR on original repo is here:

• https://github.com/jtcmedia/chocolatey-packages/pull/32

This should get approved.

[majkinetor]

/cc @AdmiringWorm

[ExE-Boss]

/cc @wget

[gep13]

@majkinetor My question is still the same though... Why create another package with a different id? Should the other package id be deprecated, and point at the new one?

[ExE-Boss]

Probably, but I’m pretty sure that that has to be done by @wget or @jtcmedia.

[majkinetor]

@gep13, I answered everything already, not sure what doesn't compute ...

[gep13]

@majkinetor said...
I answered everything already, not sure what doesn't compute ...

The question regarding the existing package still hasn't been answered. What is going to happen to it? If this is a replacement package, that is fine, but I don't think the existing package should just be left. If it is no longer going to be used, then it should be deprecated.

Also, if we are going to change the package id, then it should be updated everywhere, including the chocolateyInstall.ps1 file, which currently has this:

$packageName= 'gnupg-modern'

[ExE-Boss]

Actually, that’s chocolateyUninstall.ps1, which is probably unnecessary in this case, so I’m removing it in #1337.

[majkinetor]

The question regarding the existing package still hasn't been answered. What is going to happen to it? If this is a replacement package, that is fine, but I don't think the existing package should just be left. If it is no longer going to be used, then it should be deprecated.

I already stated several times that fixing random repository isn't something we here do. We follwed the protocol for migration and there is nothing else we can do. If you have any further comments about this you should redirect them to appropriate place.

Also, if we are going to change the package id, then it should be updated everywhere, including the chocolateyInstall.ps1 file, which currently has this

We are changing the package id becuase previous id was wrong (word modern is not something mentioned upstream) so discoverability and portability suffers. That is fairly obvious. Leftover was simply ommition that is already fixed several days ago here.

[ExE-Boss]

Now that #1337 has been merged, [email protected] should probably be re‑published before it gets approved with the legacy gnupg‑modern name present in the install and uninstall scripts:

Screenshot

[majkinetor]

Did that

[gep13]

Until there is agreement on what is going to happen with the existing package (https://chocolatey.org/packages/gnupg-modern) i.e. who is taking responsibility for deprecating the package in favour of the new one, I am not going to be approving the new package, as there is no point in duplicating packages on the community repository.

[majkinetor]

Is that really how you want to resolve this? That is, blocking users to have the latest, the most secure and most stable package because of procedure nobody really cares about and has totally different goal then what end user is interested about, making their environment use outdated and in this case insecure tools and thus dangerous for the benefit of internal jenitor operation? Especially because the things you requested could also be done after this one is approved at any time? Sounds to me a lot like failed priorities?

As this is common show stopper around here I sugest making deprecation procedure easier, such as maintainer clicking deprecate button on gallery.

/cc @ferventcoder

[gep13]

@majkinetor said...
Especially because the things you requested could also be done after this one is approved at any time? Sounds to me a lot like failed priorities?

The problem with this approach is that if _not_ done now, the chances of them getting done afterwards diminish greatly, so yes, this is exactly how I would like to proceed.

@majkinetor said...
As this is common show stopper around here I sugest making deprecation procedure easier, such as maintainer clicking deprecate button on gallery.

I think this is a great idea. So that this doesn't get lost, I would suggest that this is added as a feature request on the Gallery Repository

[majkinetor]

The problem with this approach is that if not done now, the chances of them getting done afterwards diminish greatly, so yes, this is exactly how I would like to proceed.

So lets be clear - the deprecation procedure sux which is why nobody wants to do it and yet you think that because of your stuborn insistence the whole world will suddenly have enlightment? Furthermore chocolatey employees break their own procedure all the time ( example: pauby has invokebuild package years after my package invoke-build). Whats the deal here? Some animals are more equal then others?

[majkinetor]

Anyway, I dont have energy for bike shedding here, fell free to block anything you want, I am out.

[gep13]

@majkinetor said...
Furthermore chocolatey employees break their own procedure all the time ( example: pauby has invokebuild package years after my package invoke-build). Whats the deal here? Some animals are more equal then others?

There is no "deal". Personally, I was not aware of this, and clearly this was missed during the initial review/approval of the package. Where ever possible, I attempt to prevent duplicate of both packages, and effort, when it comes to packages. As such, I have just raised this issue on @pauby repository:

https://github.com/pauby/ChocoPackages/issues/44

In my book, there is (and should be) no "favouritism" when it comes to packages that are pushed to chocolatey.org.

Let's not forget that this issue started when the existing package was renamed from the original package id, causing a duplicate package. If that hadn't been done, we wouldn't even be having this conversation. Now, I don't disagree that renaming the package id is the correct course of action, all I am saying is that the work to tidy up the artifacts left from that decision need to be completed before moving forward.

[ExE-Boss]

I think we should approve this now and finish the deprecation in https://github.com/jtcmedia/chocolatey-packages/issues/36.

[majkinetor]

You mean, we should finish the deprecation in jtcmedia/chocolatey-packages#36 and approve this now ?🗡

[gep13]

@ExE-Boss I appreciate what you are trying to do in raising that request, but as you can see, it has gone unanswered for 12 days. As a result, I am still hesitant about approving the new package until the old one is deprecated correctly.

[majkinetor]

Just out of curiosity, what happens if jtcmedia was hit by the bus (or simply doesn't care) ?

[gep13]

@majkinetor there is currently no obligation for jtcmedia alone to do the work. @wget is also a maintainer of that package, and as you well know, anyone could request to become a maintainer of the package in order to deprecate the package.

[majkinetor]

What if anybody doesn't care ?

[gep13]

Bottom line is, I, and other moderators, on chocolatey.org don't want to needlessly see duplication of packages pushed to chocolatey.org.

This is the exact situation that we have here. If no one cares to tidy up the existing package, then simply put, I won't be approving the new package. Another moderator may feel differently about this, but I would much rather see this situation fixed before approving the new package. It has been my experience that if it isn't done now, it will never get done.

[majkinetor]

If no one cares to tidy up the existing package, then simply put, I won't be approving the new package.

Wow, A-mazing.

[jtcmedia]

I was asked to migrate this package to the coreteampackages some time ago and no longer have it in my own repository. How am I supposed to deprecate it in my repository when I no longer have it?

[ExE-Boss]

@jtcmedia You just create a stub‑package according to https://chocolatey.org/docs/how-to-deprecate-a-chocolatey-package, like what I’m doing in #1360.

[majkinetor]

How am I supposed to deprecate it in my repository when I no longer have it?

Really? There is such thing on git ?

[majkinetor]

https://chocolatey.org/packages/gnupg-modern/2.2.17

[gep13]

I have just approved the gnupg package. @ExE-Boss thank you for taking the time to deprecate the old package.