obsolete dependency github.com/mtrmac/gpgme

[onlyjob]

Libpod depends on github.com/mtrmac/gpgme which is an obsolete (unmaintained) fork of github.com/proglottis/gpgme.

Please consider using the original project -- https://github.com/proglottis/gpgme

[rhatdan]

@mtrmac PTAL

[mtrmac]

This was historically forked to avoid bringing in too recent GPG symbols, which broke builds on RHEL [67].

I’m keeping an eye on the upstream from time to time, there is AFAICS nothing (definitely no feature, and no bug fix that I can see) that we would get by updating.

Sure, ideally the fork should be dropped if/when the older GPGME versions are no longer a concern. This may already be the case. There’s no urgency to it that I can see; am I missing anything?

[onlyjob]

I don't know how urgent this problem is. Probably there is no emergency.
Obsolete fork must be dropped not to gain features but for hygiene and life cycle (support) purposes.
Needless forking is harmful. Suppose you've found a problem in the library -- where would you report a bug? mtrmac doesn't even have the issue tracker. Development of this library is clearly happens in one place and that's why only the original repository should be used (instead of a fork).
It is just common sense...

[rhatdan]

@mtrmac Any update on this issue?

[mtrmac]

No

[vrothberg]

@lsm5 is that something you could look into?

You could create a branch that replaces github.com/mtrmac/gpgme with github.com/proglottis/gpgme and build that in different RHELs.

Are we still supporting consumers of c/image in RHEL 6?

[rhatdan]

No we don't support any container code on RHEL6. If we can get this built on RHEL7, then we should be fine.

[mtrmac]

Actually, I misremember — RHEL 6 was never a concern.

RHEL 7 was, though, and it ships with GPGMe 1.3.2, so we still need the extra commits in mtrmac/gpgme.

Meanwhile, there is a single bug fix in the upstream version (the rest is new functions we don’t call), and that bug fix is in a function we don’t call.

So, I’m still not all that inclined to rebase the commits, set up a RHEL 7 testing machine to ensure the result still builds, and possibly extend the revert commits on the private branch, for precisely zero benefit.

[vrothberg]

@mtrmac, I haven't checked the commits in the fork but is there any chance we could get them upstream?

[mtrmac]

See proglottis/gpgme#6 .

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[onlyjob]

@github-actions, I object to automatic closure. Even when the issue can not be fixed promptly it is still a valid issue and it does not hurt to keep it opened until it can be addressed.
Auto-closing issues is a bad practice.

[vrothberg]

@onlyjob, we configured it that way on purpose.

[rhatdan]

@onlyjob We have configured this to give us a wakeup and to attempt to rediagnose the issue. As the issue list becomes longer and longer, we loose the signal overtime. At least this causes us to revisit issues every 30 days and hopefully close some if they are fixed, or update the priority.

[mtrmac]

This will be resolved with containers/image#794 — but the existence of the separate repository is intentional and I don’t intend to closely track the upstream repository for every single release irrelevant to the containers/image/signature uses, so the “resolution” may well be considered temporary.

[vrothberg]

Closing the issue.

[onlyjob]

Thanks!