On 2020/09/06 11:26, Edd Barrett wrote: > Hi, > > On Sun, Sep 06, 2020 at 02:33:12AM +0200, Jeremie Courreges-Anglas wrote: > > This doesn't catch everything. > > Yeah, I realised shortly after. I think it's because the [^2] part of > the glob doesn't catch cases where the line ends after `security/gnupg`. > I spent a little time trying to figure out the right query, but resorted > to grep. > > Interested to know how ajacoutot@'s script works. Does it use a sqlports > query? > > > + security/p5-GPG (no consumer, not updated since import in 2001) > > ^ Shall we kill this one? > > > As Edd notes, the migration path for consumer ports may be as easy as > > replacing security/gnupg with security/gnupg2 in BUILD, RUN and > > TEST_DEPENDS, and bump REVISION. > > Below is my diff so far. This includes your latest diff to > security/gnupg2. An earlier version of this diff in a mini bulk didn't > break compilation of any of gpg's dependants. > > I wasn't sure if we need to add a pkg spec to the updated RUN/BUILD > depends, or just updating the pkg path is sufficient. > > `RUN_DEPENDS=gnupg->=2:security/gnupg2` vs. just > `RUN_DEPENDS=security/gnupg2`. > > We will also need to add a quirk to ensure that gnupg1 updates to > gnupg2 properly.
Not needed, the stem is the same so they are both considered as long as a matching pkgpath is declared. I think we should just replace security/gnupg with 2.x though. > > Regarding the user migration path, the compat "gpg2" and "gpgv2" > > symlinks could be removed for 6.9, or this could be done post-release. > > I would go with the latter but I don't feel strongly about it. > > I'm thinking post-release too. We are bound to encounter breakage, and > it'd be good to limit that to -current if possible. I don't see harm in keeping symlinks for the existing binaries, they may be used in user configurations and scripts in various places on the system and I don't think there's a good reason to break these.
