| View previous topic :: View next topic |
| Author |
Message |
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
 Posted: Sun Dec 17, 2017 10:45 pm Post subject: gpgme - same version now wants gnupg-2 rather than gnupg |
 |
|
For some reason gpgme-1.8.0 appears to have developed a dependence on gnupg-2 rather than gnupg. This happened at some point between 9 December 2017 and 16 December 2017.
I am using gnupg rather than gnupg-2, the change in gpgme results in an attempt to pull in gnupg-2 plus agent etc which I do not want.
| Code: | | emerge-webrsync --revert=20171209 |
then copying gpgme to my local overlay followed by returns previous behaviour on my system ... why do these changes happen with no revision to versions especially since the previous ebuild works ?
Since the change log does not appear to be visible anymore with rsync ... it does not appear to be straightforward to work out why someone has made this change. Not sure if this a bug or not ... |
|
| Back to top |
|
 |
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Sun Dec 17, 2017 11:49 pm Post subject: |
|
|
Well, going through the portage log (the portage tree is now in git, and that's where the log is maintained; you can view the log easily enough through the portage tree from the site on your browser).
Anyways, the log says the change was done, due to this Bug 640858 - app-crypt/gpgme-1.10.0 : checking for GPG Error - version >= 1.24... yes (1.27) .
In short, at the bottom of the comments indicated that gnupg-1.4.21 is soon to be given last rites and masked for removal. So I would say, this is the intention, by shifting everything away from the old version prior to removing that version of gnupg. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22745
|
| Posted: Sun Dec 17, 2017 11:56 pm Post subject: |
|
|
Speaking generally, with no context beyond what was posted in this thread:
The ebuild was likely changed without a revision bump specifically because the previous ebuild worked for the people who had installed it, and the change brought no value to people who already had a working install. That rationale is typically used to justify fixing issues that broke the build for some configurations, and ran fine for others. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Dec 18, 2017 12:45 am Post subject: |
|
|
| ct85711 wrote: | | In short, at the bottom of the comments indicated that gnupg-1.4.21 is soon to be given last rites and masked for removal. So I would say, this is the intention, by shifting everything away from the old version prior to removing that version of gnupg. |
ct85711, et al ... that would make sense if gnupg-1 were in fact discontinued, but that isn't the case, the 1.x series is still being developed, as shown by the maintainance release (1.4.22) from 2017-07-19 (fixing CVE-2017-7526).
IMO, this is another case of developers doing shoddy fixes, there is nothing wrong with gnupg-1 and if gpgme actually requires 2.x then it should DEPEND on it (you know, the standard method for dealing with such issues). Dropping <app-crypt/gnupg-2.x just because some other package happens to have some issue is basically dumb, and can only be explained by the fact that the developer(s) involved in its removal don't use gnupg-1 ... and so think no one should be.
best ... khay |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Mon Dec 18, 2017 1:21 am Post subject: |
|
|
I can not say about what the devs does is correct or not, I am just going by what they put in the bug report I linked to; more of Comments 8 & 9 saying in short:
| Quote: | | Maybe a good reason to mask 1.4 in the gentoo repo and get ready to remove it altogether. |
| Quote: | | Yes, can you please? we do not need it around any more. |
This to me sounds like, they (the devs) are getting ready to mask gnupg-1.4 for removal... Going by this bug was just closed on the 13th; I am assuming they are verifying this won't break any other package and/or haven't got around to masking it yet. Now if and/or when they do mask/remove it, I don't know how long until it happens. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9313
|
| Posted: Mon Dec 18, 2017 1:46 am Post subject: |
|
|
| khayyam wrote: | | IMO, this is another case of developers doing shoddy fixes, there is nothing wrong with gnupg-1 and if gpgme actually requires 2.x then it should DEPEND on it (you know, the standard method for dealing with such issues). Dropping <app-crypt/gnupg-2.x just because some other package happens to have some issue is basically dumb, and can only be explained by the fact that the developer(s) involved in its removal don't use gnupg-1 ... and so think no one should be. |
We have plenty of stable(!) gnupg versions in tree, if you can't come up with a compelling reason why gnupg-1 should be kept in tree other than a smug comment, then off it goes.
| Code: | $ eshowkw app-crypt/gnupg
Keywords for app-crypt/gnupg:
| | u |
| a a p a n r s | n |
| l m h i p r m m i i s p | e u s | r
| p d a p a p c x m i 6 o s 3 a | a s l | e
| h 6 r p 6 p 6 8 6 p 8 s c 9 s r | p e o | p
| a 4 m a 4 c 4 6 4 s k 2 v 0 h c | i d t | o
------------+---------------------------------+-------+-------
1.4.21 | + + + + + + + + o ~ o o o ~ ~ + | 5 # 0 | gentoo
2.1.15 | + + + + + + + + + ~ + o o + + + | 5 o | gentoo
2.1.20-r1 | + + + + + + + + + ~ ~ o o ~ ~ + | 6 o | gentoo
2.2.0 | + + + + + + + + ~ ~ ~ o o ~ ~ ~ | 6 o | gentoo
2.2.1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ ~ | 6 # | gentoo
[I]2.2.3 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ ~ | 6 o | gentoo |
|
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22745
|
| Posted: Mon Dec 18, 2017 4:45 am Post subject: |
|
|
| Upstream changed several obvious user-visible behaviours in gnupg-2. Some people object to this, preferring how it worked in gnupg-1.4. I can't say whether that's a good enough reason to keep the 1.x line, but it's definitely not the case that upgrading to 2.x is free of undesirable quirks. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Dec 18, 2017 9:05 am Post subject: |
|
|
| asturm wrote: | | We have plenty of stable(!) gnupg versions in tree, if you can't come up with a compelling reason why gnupg-1 should be kept in tree other than a smug comment, then off it goes. |
astrum ... ok, for one: as shown above, it's supported by upstream! How's that for "smug"? |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Mon Dec 18, 2017 9:34 pm Post subject: |
|
|
This smells a bit like gentoo's bungled blood crusade to purge the tree of GTK2 support a few years back... while the software using it actually worked fine (and still does today - GTK3 still isn't safe to write themes for, so nobody does).
| asturm wrote: | | We have plenty of stable(!) gnupg versions in tree, if you can't come up with a compelling reason why gnupg-1 should be kept in tree other than a smug comment, then off it goes. |
Does the ebuild for gpg2 patch back in the PGP2 support that has been removed? Data loss is a pretty compelling reason. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9313
|
| Posted: Mon Dec 18, 2017 10:34 pm Post subject: |
|
|
| khayyam wrote: | | as shown above, it's supported by upstream! How's that for "smug"? |
That's not reason enough; plenty of software is supported upstream and we don't package it - it still needs someone to take care of it. You can turn a hypothetical last-rites thread into a bikeshed and maybe you succeed in that it is not dropped; but then you likely end up with a bitrotting old ebuild because no dev is left using or testing it.
| Ant P. wrote: | | Data loss is a pretty compelling reason. |
Sure that is. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Dec 19, 2017 12:20 am Post subject: |
|
|
| asturm wrote: | | khayyam wrote: | | as shown above, it's supported by upstream! How's that for "smug"? |
That's not reason enough; plenty of software is supported upstream and we don't package it - it still needs someone to take care of it. |
astrum ... it's plenty reason, and others have provided additional reasons. Having supplied it you're now trying to make it seem as though maintaining that one ebuild is some huge task, and that there is some deeper issue involved, this is complete nonsense. Stop acting as though "developers" are doing something for us users, and that the entire burden of "support", Q&A, etc, is born by them ... it's a familiar trope, and serves no other purpose than to make developers seem somehow superior to the community they serve. Such a package should be maintained because it provides choice, and given the fact that upstream maintain it (even if only for fixes, CVE's, etc), it makes little sense not to do similar if some benefit to the community can be had.
| asturm wrote: | | You can turn a hypothetical last-rites thread into a bikeshed and maybe you succeed in that it is not dropped; but then you likely end up with a bitrotting old ebuild because no dev is left using or testing it. |
We can add it to the list, there are no end of packages, useflag combinations, etc, etc, etc, that are never tested, so what is your point here? By throwing in the term "bitrot" you are attempting to make the issue seem critical, and/or requiring action, when the package is maintained upstream, and there is very little work, or action, required. If in the unlikely event that some action is required then you can hope, as per standard practice, users report it, and that action can be taken, but that certainly isn't the case so far, the package is bumped as and when new releases are made upstream, as happened on 2017-07-19. So, there isn't a lot that is being asked here, the solution is a no brainer.
best ... khay |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9313
|
| Posted: Tue Dec 19, 2017 12:44 am Post subject: |
|
|
| khayyam wrote: | | it's plenty reason |
Nope.
| khayyam wrote: | | Having supplied it you're now trying to make it seem as though maintaining that one ebuild is some huge task |
Wrong, talking in general. Just multiply 'that one ebuild' by the hundreds. I can't possibly talk about gnupg specifically because I've never looked at it.
| khayyam wrote: | | Stop acting as though "developers" are doing something for us users, and that the entire burden of "support", Q&A, etc, is born by them ... it's a familiar trope, and serves no other purpose than to make developers seem somehow superior to the community they serve. |
Drivel.
| khayyam wrote: | | Such a package should be maintained because it provides choice, and given the fact that upstream maintain it (even if only for fixes, CVE's, etc), it makes little sense not to do similar if some benefit to the community can be had. |
I did not deny that it should be maintained if there is a compelling reason. Mere existence is not. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Dec 19, 2017 1:57 am Post subject: |
|
|
| asturm wrote: | | khayyam wrote: | | it's plenty reason, and others have provided additional reasons. |
Nope. |
astrum ... you're proving to be a disingenuous, and dishonest, interlocutor, with your selective quoting (fixed in the above).
| asturm wrote: | | khayyam wrote: | | Having supplied it you're now trying to make it seem as though maintaining that one ebuild is some huge task |
Wrong, talking in general. Just multiply 'that one ebuild' by the hundreds. I can't possibly talk about gnupg specifically because I've never looked at it. |
You asked for "a" reason, I provided "one", I could provide more but I see little point "discussing" it with you.
| asturm wrote: | | khayyam wrote: | | Stop acting as though "developers" are doing something for us users, and that the entire burden of "support", Q&A, etc, is born by them ... it's a familiar trope, and serves no other purpose than to make developers seem somehow superior to the community they serve. |
Drivel. |
That is ironic, given the arguments (sic) you've used so far in this thread. Stating something is "drivel" is a great retort, but it doesn't constitute an argument.
| asturm wrote: | | khayyam wrote: | | Such a package should be maintained because it provides choice, and given the fact that upstream maintain it (even if only for fixes, CVE's, etc), it makes little sense not to do similar if some benefit to the community can be had. |
I did not deny that it should be maintained if there is a compelling reason. Mere existence is not. |
No, you were just asking for "a" reason, both Hu, and Ant P. provided them, that is disengeniousness at it's core. Now you still need "a compelling reason" because you are effectively lording over what such a reason might involve, and throwing in all manor of distractions in the form of "bitrot", the work involved, etc. In short, trolling.
Last edited by khayyam on Tue Dec 19, 2017 2:04 am; edited 1 time in total |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9313
|
| Posted: Tue Dec 19, 2017 2:01 am Post subject: |
|
|
| You're just a waste of time. |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Wed Dec 20, 2017 9:59 pm Post subject: |
|
|
I think I first masked gnupg-2 a few years ago because claws-mail would behave quite oddly with gnupg-2 (I think it used to prompt for the password in a virtual console  ) ... I'll stick with gnupg-1 for the moment but based on that bug can expect to be forced at some point to switch to gnupg-2. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
