First and foremost, sorry, for the f'up on the subject....
I changed it now, to a bit more relevant subject
>> 1 What is the difference between gnupg2 and gnupg-2.X.X?
>
> Possibly quite a lot. GnuPG exists in three different branches.
> For sake of simplicity I'll call them "modern", "standard", and
> "classic".
>
> Modern: GnuPG 2.3 and later.
> Standard: GnuPG 2.2
> Classic: GnuPG 1.4
>
> The differences among them are principally what version of the
> OpenPGP standard they track. OpenPGP has been around for decades.
> The Modern branch has some bells and whistles the other two lack
> (principally authenticated encryption, which *technically* exists in
> the other two, but the Modern branch does it in a technically
> superior way).
>
> Standard and Classic are roughly equivalent in terms of features,
> but Standard exists to support desktop environments, while Classic
> may be more useful in standalone server environments.
>
> We would like to see Classic go away and move everything to Modern,
> but that's not possible right now. Maybe not ever.
>
>> It is looking for gnupg2 but currently my compilation is as gnupg.
>
> If you're downloading the 2.2 or 2.3 branches, you can set the
> executable name by passing a flag to ./configure. I think it's
> "--program-suffix=2" will add a 2 to the end of all the binaries
> created by GnuPG. Or, to just set the name of the gpg binary to
> gpg2, use "--enable-gpg-is-gpg2".
>
It seems not as much the binary name seemed the problem but the
dnf/yum/rpm dependency.
It was looking to install a gnupg2 packet while there is a gnupg
packet already installed.
Hence my try to rename everything to gnupg2 but that does not work for
the source tarball.
But all gnupg-2.x.x are basically gnupg2, no matter how I name the
binary, right?
Can I generate both binaries (gpg AND gpg2)?
Does linking work?
For now I solved that problem with a 'Provides:' clause in my .SPEC file.
And currently I am stuck at the next problem.
With the 'Provides:' clause the dnf did recognize my gpg as valid and
updated/installed all other files.
But now I have a non-working dnf
# dnf
Traceback (most recent call last):
File "/opt/freeware/bin/dnf", line 57, in <module> from dnf.cli import main
File "/opt/freeware/lib/python3.7/site-packages/dnf/__init__.py",
line 32, in <module> import dnf.base
File "/opt/freeware/lib/python3.7/site-packages/dnf/base.py", line
29, in <module> import libdnf.transaction
File
"/opt/freeware/lib/python3.7/site-packages/libdnf/__init__.py", line
3, in <module> from . import common_types
File
"/opt/freeware/lib/python3.7/site-packages/libdnf/common_types.py",
line 13, in <module> from . import _common_types
ImportError: rtld: 0712-001 Symbol _GLOBAL__AIXI_libgpg_error_so
was referenced
from module
/opt/freeware/lib/python3.7/site-packages/libdnf/_common_types.so(),
but a runtime definition of the symbol was not found.
rtld: 0712-001 Symbol _GLOBAL__AIXD_libgpg_error_so was referenced
from module
/opt/freeware/lib/python3.7/site-packages/libdnf/_common_types.so(),
but a runtime definition of the symbol was not found.
> Hope this helps. :)
It definitely does, thanks.
Hope you can help me a bit more.
Kind regards
Frank
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
I changed it now, to a bit more relevant subject
>> 1 What is the difference between gnupg2 and gnupg-2.X.X?
>
> Possibly quite a lot. GnuPG exists in three different branches.
> For sake of simplicity I'll call them "modern", "standard", and
> "classic".
>
> Modern: GnuPG 2.3 and later.
> Standard: GnuPG 2.2
> Classic: GnuPG 1.4
>
> The differences among them are principally what version of the
> OpenPGP standard they track. OpenPGP has been around for decades.
> The Modern branch has some bells and whistles the other two lack
> (principally authenticated encryption, which *technically* exists in
> the other two, but the Modern branch does it in a technically
> superior way).
>
> Standard and Classic are roughly equivalent in terms of features,
> but Standard exists to support desktop environments, while Classic
> may be more useful in standalone server environments.
>
> We would like to see Classic go away and move everything to Modern,
> but that's not possible right now. Maybe not ever.
>
>> It is looking for gnupg2 but currently my compilation is as gnupg.
>
> If you're downloading the 2.2 or 2.3 branches, you can set the
> executable name by passing a flag to ./configure. I think it's
> "--program-suffix=2" will add a 2 to the end of all the binaries
> created by GnuPG. Or, to just set the name of the gpg binary to
> gpg2, use "--enable-gpg-is-gpg2".
>
It seems not as much the binary name seemed the problem but the
dnf/yum/rpm dependency.
It was looking to install a gnupg2 packet while there is a gnupg
packet already installed.
Hence my try to rename everything to gnupg2 but that does not work for
the source tarball.
But all gnupg-2.x.x are basically gnupg2, no matter how I name the
binary, right?
Can I generate both binaries (gpg AND gpg2)?
Does linking work?
For now I solved that problem with a 'Provides:' clause in my .SPEC file.
And currently I am stuck at the next problem.
With the 'Provides:' clause the dnf did recognize my gpg as valid and
updated/installed all other files.
But now I have a non-working dnf
# dnf
Traceback (most recent call last):
File "/opt/freeware/bin/dnf", line 57, in <module> from dnf.cli import main
File "/opt/freeware/lib/python3.7/site-packages/dnf/__init__.py",
line 32, in <module> import dnf.base
File "/opt/freeware/lib/python3.7/site-packages/dnf/base.py", line
29, in <module> import libdnf.transaction
File
"/opt/freeware/lib/python3.7/site-packages/libdnf/__init__.py", line
3, in <module> from . import common_types
File
"/opt/freeware/lib/python3.7/site-packages/libdnf/common_types.py",
line 13, in <module> from . import _common_types
ImportError: rtld: 0712-001 Symbol _GLOBAL__AIXI_libgpg_error_so
was referenced
from module
/opt/freeware/lib/python3.7/site-packages/libdnf/_common_types.so(),
but a runtime definition of the symbol was not found.
rtld: 0712-001 Symbol _GLOBAL__AIXD_libgpg_error_so was referenced
from module
/opt/freeware/lib/python3.7/site-packages/libdnf/_common_types.so(),
but a runtime definition of the symbol was not found.
> Hope this helps. :)
It definitely does, thanks.
Hope you can help me a bit more.
Kind regards
Frank
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
