Re: Move to versioned pam-gnupg

Re: Move to versioned pam-gnupg

[daniel-eys]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

New comment by daniel-eys on void-packages repository

https://github.com/void-linux/void-packages/pull/19645#issuecomment-593028911

Comment:
You can add `replaces="pam-gnupg-git>=0"` to the new template. This should do the migration without the transitional meta-package.

Re: Move to versioned pam-gnupg

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/19645#issuecomment-593047034

Comment:
> You can add `replaces="pam-gnupg-git>=0"` to the new template. This should do the migration without the transitional meta-package.

This was my first inclination, but @Duncaen didn't think `replaces` was sufficient and recommended the meta-package approach. It would be great to get his feedback on the matter here.

Re: Move to versioned pam-gnupg

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/19645#issuecomment-593048342

Comment:
A quick test suggests that adding a `replaces` directive is not sufficient to identify the upgrade path from `pam-gnupg-git` to `pam-gnupg`. With the new `pam-gnupg` package (with a `replaces` directive) available in a local repository, `xbps-install pam-gnupg` will properly cause removal of an installed `pam-gnupg-git-20191206_1`. However, `xbps-install -u` from the local repo will *not* attempt to replace the installed `pam-gnupg-git-20191206_1` with the new `pam-gnupg` whether or not the `replaces` directive is included.

By contrast, having an updated `pam-gnupg-git` metapackage in the local repo causes `xbps-install -u` to properly replace the existing installation, pulling in the new `pam-gnupg` by dependence.

Re: Move to versioned pam-gnupg

[daniel-eys]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

New comment by daniel-eys on void-packages repository

https://github.com/void-linux/void-packages/pull/19645#issuecomment-593102702

Comment:
Right, I see now. Only an explicit `xpbs-install pam-gnupg` would pick up the changes in the case when `pam-gnupg-git` is already installed.
Then indeed, having a metapackage should be the proper choice here.

Re: Move to versioned pam-gnupg

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]

New comment by xtraeme on void-packages repository

https://github.com/void-linux/void-packages/pull/19645#issuecomment-593107023

Comment:
Right, the meta pkg allows you to upgrade it even with incompatible version upgrades. 

Re: Move to versioned pam-gnupg

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

New comment by xtraeme on void-packages repository

https://github.com/void-linux/void-packages/pull/19645#issuecomment-593883226

Comment:
Anyway, next time we should be more careful when adding pkgs with git commits...

Re: [PR PATCH] [Merged]: Move to versioned pam-gnupg

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

There's a merged pull request on the void-packages repository

Move to versioned pam-gnupg
https://github.com/void-linux/void-packages/pull/19645

Description:
This PR makes pam-gnupg-git a meta-package that depends on the new pam-gnupg package, which is a proper release version of the pam-gnupg module. The migration does not seem to work when pam-gnupg-git is a subpackage of pam-gnupg because the change from date-based versioning (20191206_1) to release versioning (0.1_1) is not properly ordered and XBPS will not recognize that the new meta-package is an upgrade to the earlier version.

The plan is to keep the pam-gnupg-git meta-package around for awhile---maybe until the next upstream release (I do not suspect that this is a popular package), then remove it and continue only with the new release-based package.