app-crypt/seahorse has a specific || ( =app-crypt/gnupg-2.0* =app-crypt/gnupg-1.4* ) dependency blocking an upgrade to GnuPG 2.1.0 release in final version today[0]. Is there any reason for this limitation rather than a non-versioned dependency? References: [0] http://lists.gnupg.org/pipermail/gnupg-announce/2014q4/000358.html
I do not see any reason, we never had anything else, and since introduction of 2.0 there was no side-by-side.
I think I explained this a while ago to someone asking on #-dev. There is no reason for being blocked to 2.0. The only thing this || is about is to allow people to keep gnupg-1.4 without having package manager force the upgrade to >=2 all the time.
there is no need to support 1.4 in a system that runs gnome. 1.4 has value only (and if) in initramfs and such. I also do not see a reason why app-crypt/gnupg should not be a dependency instead of this complex condition.
We sure had bug requesting this particular kind of dependency. I have no objections myself to one or another form.
(In reply to Gilles Dartiguelongue from comment #2) > There is no reason for being blocked to 2.0. The only thing this || is about > is to allow people to keep gnupg-1.4 without having package manager force > the upgrade to >=2 all the time. || ( =app-crypt/gnupg-2* =app-crypt/gnupg-1.4* ) could be used to preserve this behavior.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) > (In reply to Gilles Dartiguelongue from comment #2) > > There is no reason for being blocked to 2.0. The only thing this || is about > > is to allow people to keep gnupg-1.4 without having package manager force > > the upgrade to >=2 all the time. > > || ( =app-crypt/gnupg-2* =app-crypt/gnupg-1.4* ) could be used to preserve > this behavior. I still don't see the benefit of it, if they don't want an upgrade to 2.x use a local package.mask on the >=app-crypt/gnupg-2.0.0 atom as 1.4 and 2.0 is in the same slot. I do this myself on some servers, which is really the only environment where using 1.4 can make sense (although mostly not, in particular since the pinentry loopback feature of 2.1 again). FWIW, Elliptic Curves will only exist in 2.1 and not be backported to the classic versions.
From my point of view I would simply depend on >= 1.4
Any update on this issue? @gnome: Would you prefer if I make the necessary dep changes myself?
Would it be safe to change this concrete dep from its current || () form to simply >= in the current ebuilds? Or should we revbump it for that change?
(In reply to Pacho Ramos from comment #9) > Would it be safe to change this concrete dep from its current || () form to > simply >= in the current ebuilds? Or should we revbump it for that change? You very likely wouldn't even need any >= in the first place as 1.4 is oldest in the tree with first version released about 10 years ago, and this is the oldest branch being maintained upstream so there won't be older versions re-introduced. This can be updated without a revbump.
can we please progress in this? should be trivial and harmless.
+ 30 Dec 2014; Pacho Ramos <pacho@gentoo.org> seahorse-3.12.2.ebuild, + seahorse-3.14.0.ebuild: + Move away from || () gnupg dependency to plain >= requirement, bug #528460 by + Kristian Fiskerstrand and Alon Bar-Lev +
