[gentoo-dev] One-Day Gentoo Council Reminder for December
This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
Alon Bar-Lev wrote: As I told you before, I wont slot these two. Could you provide a link to reasons that lead you to this decision so that interested readers can make their own opinion? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI placement
Doug Klima kirjoitti: Since it doesn't appear the question was answered by the last thread. I'm starting a new thread. http://article.gmane.org/gmane.linux.gentoo.devel/52981/match=eapi I think it was answered. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On K, 2007-12-12 at 07:07 +0200, Alon Bar-Lev wrote: On 12/12/07, William L. Thomson Jr. [EMAIL PROTECTED] wrote: ...We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. As I told you before, I wont slot these two. I would like to have the option to have a smaller gnupg version in the shape of a well maintained upstream GnuPG-1 for any embedded or handheld devices I might acquire in the future, as I would only need OpenPGP support on such a limited disk and resource device. Please state a reason for not providing me, and many other users and developers alike, from such a choice. With no slotting I can bet on GnuPG-1 going away shortly after all architectures have stabled GnuPG-2, or is that not so and such users can mask =GnuPG-1.9 and keep using a smaller version that perfectly fits their needs? If yes, why not slot it as is designed? Regards, Mart Raudsepp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote: Alon Bar-Lev wrote: As I told you before, I wont slot these two. Could you provide a link to reasons that lead you to this decision so that interested readers can make their own opinion? http://bugs.gentoo.org/show_bug.cgi?id=159623 Best Regards, Alon Bar-Lev.
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 12/12/07, Mart Raudsepp [EMAIL PROTECTED] wrote: With no slotting I can bet on GnuPG-1 going away shortly after all architectures have stabled GnuPG-2, gpg-1.X series will be available as long as upstream maintain it. or is that not so and such users can mask =GnuPG-1.9 and keep using a smaller version that perfectly fits their needs? If yes, why not slot it as is designed? Slotting makes logic if there is some advantage of having both slots installed at the same machine, as gnupg-2 does all gnupg-1 does, there is no point in slotting, forcing users to mess with eselect in order to resolve the dependency of other packages with gnupg. You can always mask =gnupg-2 if you want the 1.X series on embedded devices. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima [EMAIL PROTECTED] wrote: discuss. * EAPI may only be set before the 'inherit' in an ebuild. * Eclasses may not set EAPI. * Eclasses may not assume a particular EAPI. * If an eclass needs to work with multiple EAPIs, EAPI-specific code should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code and a conditional inherit should remain in foo.eclass. * Eclasses cannot be made not to work with any given EAPI. If such functionality is desirable, someone needs to file an EAPI request for permitting an alternative to 'die' that is legal in global scope. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI placement
On Dec 12, 2007 1:21 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima [EMAIL PROTECTED] wrote: discuss. * EAPI may only be set before the 'inherit' in an ebuild. * Eclasses may not set EAPI. * Eclasses may not assume a particular EAPI. * If an eclass needs to work with multiple EAPIs, EAPI-specific code should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code and a conditional inherit should remain in foo.eclass. It seems the most reasonable option I've read until now. Would it be possible to have eclass/eapiBLAH/foo.eclass? * Eclasses cannot be made not to work with any given EAPI. If such functionality is desirable, someone needs to file an EAPI request for permitting an alternative to 'die' that is legal in global scope. So is it desirable? If portage masks ebuilds with an unsupported EAPI, what's the point? It'd be enough to be able to check EAPI compatibility in eclasses quickly so repoman and others can print a nice error. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
Petteri Räty wrote: Doug Klima kirjoitti: Since it doesn't appear the question was answered by the last thread. I'm starting a new thread. http://article.gmane.org/gmane.linux.gentoo.devel/52981/match=eapi I think it was answered. Regards, Petteri And I brough up valid reasons with zmedico why putting it before the inherit line was flawed currently since it could lead to some seriously unexpected behavior. If that's the case, it needs to be a very strict check in repoman and we need repoman on the eclasses to prevent people from putting EAPI into the eclasses. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Wed, 12 Dec 2007 15:08:36 +0100 Santiago M. Mola [EMAIL PROTECTED] wrote: Would it be possible to have eclass/eapiBLAH/foo.eclass? No. Not even with an EAPI change. This is one of the deficiencies in the way EAPI was designed -- an EAPI cannot change the behaviour of inherit, nor can it introduce new global-scope functions. The .ebuild-eapi proposal didn't have this problem, but unfortunately it was rejected for political reasons... * Eclasses cannot be made not to work with any given EAPI. If such functionality is desirable, someone needs to file an EAPI request for permitting an alternative to 'die' that is legal in global scope. So is it desirable? If portage masks ebuilds with an unsupported EAPI, what's the point? It'd be enough to be able to check EAPI compatibility in eclasses quickly so repoman and others can print a nice error. The problem is that people change eclasses and don't check every single package that uses them. Find a solution for that problem and then eclasses supporting only a subset of EAPIs becomes feasible. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI placement
On Wed, 12 Dec 2007 09:20:02 -0500 Doug Klima [EMAIL PROTECTED] wrote: And I brough up valid reasons with zmedico why putting it before the inherit line was flawed currently since it could lead to some seriously unexpected behavior. It's only unexpected if people screw up. If everyone understands the restrictions I posted and sticks to them then things work. If people start trying to be clever things go horribly wrong. If that's the case, it needs to be a very strict check in repoman and we need repoman on the eclasses to prevent people from putting EAPI into the eclasses. Or you need to get PMS and package managers retroactively updated to saying that 'inherit' does a 'declare -r EAPI'... Although that's only a good idea if you operate on the assumption that developers will screw up. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI placement
Ciaran McCreesh wrote: On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima [EMAIL PROTECTED] wrote: discuss. * EAPI may only be set before the 'inherit' in an ebuild. * Eclasses may not set EAPI. * Eclasses may not assume a particular EAPI. * If an eclass needs to work with multiple EAPIs, EAPI-specific code should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code and a conditional inherit should remain in foo.eclass. * Eclasses cannot be made not to work with any given EAPI. If such functionality is desirable, someone needs to file an EAPI request for permitting an alternative to 'die' that is legal in global scope. My point is it's fine to state this, however there needs to be enforcement of this in the associated utilities. repoman, etc. Unfortunately, eclasses are not checked at all at commit time, which would allow developers to make this potentially catastrophic change. So we're going to have eapi 1 inherit foo-eapi1.eclass allowable in foo.eclass? When will this eapi keyword be available for eclasses to use? -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Use the Log
Hi everyone, this is a reminder especially for architecture people: Please use the ChangeLog and really log everything you did. Don't do a change and forget to document it. Oh and please don't forget to remove your arches from the cc field if there is a bug. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI placement
On Wed, 12 Dec 2007 09:22:41 -0500 Doug Klima [EMAIL PROTECTED] wrote: My point is it's fine to state this, however there needs to be enforcement of this in the associated utilities. repoman, etc. Unfortunately, eclasses are not checked at all at commit time, which would allow developers to make this potentially catastrophic change. Well, the other option is to enforce it via the package manager. But that's enforcing tree policy via EAPI, which we were trying to avoid. So we're going to have eapi 1 inherit foo-eapi1.eclass allowable in foo.eclass? When will this eapi keyword be available for eclasses to use? [[ $EAPI == 1 ]] Adding an eapi keyword would require a new EAPI, so you'd have to do the variable test for 0 and 1 anyway (and note that the empty EAPI is exactly like EAPI 0, and you can't assume that you'll get one or the other). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote: On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote: Alon Bar-Lev wrote: As I told you before, I wont slot these two. Could you provide a link to reasons that lead you to this decision so that interested readers can make their own opinion? http://bugs.gentoo.org/show_bug.cgi?id=159623 Again while there might not be technical issues, what is not covered there in the bug is why rob users of a choice? Why make users mask a 2.0 version that's in the same slot as a 1.4.x version. Given that both will be actively maintained. If they are the same, why maintain 1.4.x at all? Kinda contradicts your justification and statements that gnupg-2 is a FULL replacement for gnupg-1. Plus your making Gentoo the ONLY distro where gnupg-1 and gnupg-2 can't be installed together. Just as upstream DESIGNED them. Nice one ;) And as I said then and now, good luck on stabilization ;) That's coming over a year after gnupg-2 was released. Can someone change the freaking broken record ;) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI placement
On Wednesday 12 of December 2007 15:20:19 Ciaran McCreesh wrote: The .ebuild-eapi proposal didn't have this problem, but unfortunately it was rejected for political reasons... I wasn't around then, but the requirment of actually sourcing the ebuild to read the EAPI value is extremely stupid indeed. Let's change it... -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
Ciaran McCreesh wrote: On Wed, 12 Dec 2007 09:20:02 -0500 Doug Klima [EMAIL PROTECTED] wrote: And I brough up valid reasons with zmedico why putting it before the inherit line was flawed currently since it could lead to some seriously unexpected behavior. It's only unexpected if people screw up. If everyone understands the restrictions I posted and sticks to them then things work. If people start trying to be clever things go horribly wrong. If that's the case, it needs to be a very strict check in repoman and we need repoman on the eclasses to prevent people from putting EAPI into the eclasses. Or you need to get PMS and package managers retroactively updated to saying that 'inherit' does a 'declare -r EAPI'... Although that's only a good idea if you operate on the assumption that developers will screw up. That's the assumption I'm operating under because you and I both know if repoman and friends don't prevent it, it will happen. We can have all the docs in the world, but if we don't go about some steps to prevent bad things from happening. They can and will. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
Alon Bar-Lev wrote: On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote: Alon Bar-Lev wrote: As I told you before, I wont slot these two. Could you provide a link to reasons that lead you to this decision so that interested readers can make their own opinion? http://bugs.gentoo.org/show_bug.cgi?id=159623 I've read it, thanks. Are you referring to There is no point in installing the TWO (means slot) at the same time., or do you have something else? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Wed, 2007-12-12 at 14:30 +0200, Alon Bar-Lev wrote: Slotting makes logic if there is some advantage of having both slots installed at the same machine, Guess it's never been clear to you in upstream announcement that gnupg-1 BENEFITS from gnupg-2 co-existing. Again go back and read the announcement. as gnupg-2 does all gnupg-1 does, It does NOT, do a comparison of command line args. there is no point in slotting, forcing users to mess with eselect in order to resolve the dependency of other packages with gnupg. You keep bringing up eselect when there is NO need. Apps that are designed for gnupg2 call gpg2 or link to the -2 version of the .so. Done, and NO need for eselect. That BS has flown, been sold, or bought for over a year now :) Try again with some more BS reasons not to slot :) You can always mask =gnupg-2 if you want the 1.X series on embedded devices. Which I have done for my desktop use for 6 months now. Masking to use a current version of a package version that will continue to be maintained in the same slot as a newer version is quite stupid. IMHO. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Use the Log
Christian Faulhammer wrote: Hi everyone, this is a reminder especially for architecture people: Please use the ChangeLog and really log everything you did. Don't do a change and forget to document it. Oh and please don't forget to remove your arches from the cc field if there is a bug. V-Li We've all made this request and made comments about this. The arches in question will not change. They've been doing it like that for years. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Dec 12, 2007 4:08 PM, William L. Thomson Jr. [EMAIL PROTECTED] wrote: On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote: On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote: Alon Bar-Lev wrote: As I told you before, I wont slot these two. Could you provide a link to reasons that lead you to this decision so that interested readers can make their own opinion? http://bugs.gentoo.org/show_bug.cgi?id=159623 Again while there might not be technical issues, what is not covered there in the bug is why rob users of a choice? Why make users mask a 2.0 version that's in the same slot as a 1.4.x version. Given that both will be actively maintained. In short: * It's upstream's choice. * 2 is actively maintained and there's no deprectation planned. * It's not a true drop-in replacement, even if it's fully compatible with all packages in the tree. * In some cases, people could get a benefit of using gpg-1, instead of gpg-2. * There's no need of an eselect module, since gpg2 is supposed to be called gpg2 and not just gpg. * Again, it's upstream choice and, after considering the possibilities, there's no major reason for not following it. What else is needed for using SLOTs? -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Use the Log
Christian Faulhammer wrote: Hi everyone, this is a reminder especially for architecture people: Please use the ChangeLog and really log everything you did. Don't do a change and forget to document it. Oh and please don't forget to remove your arches from the cc field if there is a bug. V-Li Go ia64! -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
William L. Thomson Jr. wrote: On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote: On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote: Alon Bar-Lev wrote: As I told you before, I wont slot these two. Could you provide a link to reasons that lead you to this decision so that interested readers can make their own opinion? http://bugs.gentoo.org/show_bug.cgi?id=159623 Again while there might not be technical issues, what is not covered there in the bug is why rob users of a choice? Why make users mask a 2.0 version that's in the same slot as a 1.4.x version. Given that both will be actively maintained. If they are the same, why maintain 1.4.x at all? Kinda contradicts your justification and statements that gnupg-2 is a FULL replacement for gnupg-1. Plus your making Gentoo the ONLY distro where gnupg-1 and gnupg-2 can't be installed together. Just as upstream DESIGNED them. Nice one ;) And as I said then and now, good luck on stabilization ;) That's coming over a year after gnupg-2 was released. Can someone change the freaking broken record ;) Why don't you step up and offer to help maintain this? If I was Alon, I wouldn't want to do maintain both just cause you wanted me to. It increases maintenance load and work he has to do and since he's a volunteer it's all about scratching his personal itch, since this doesn't for him.. why should he do it. Clearly it gives you an itch, so setup up and offer to help maintain. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Wed, 2007-12-12 at 11:11 -0500, Doug Klima wrote: William L. Thomson Jr. wrote: Why don't you step up and offer to help maintain this? If your asking me, because I am already over committed. I can't be in all places doing all things. Plus in this regard I am just a user, and we should not require devs to step up and maintain every package they use. Usually it's polite for other devs to look out there if they are maintaining a package that regular users much less other devs use. Specific to Doug, like in the case of Firebird if you made a good case for needing 1.5.x back in tree. I would likely oblige, despite my own opinion and removing it. To try to be cooperative with other devs and not force them to maintain a version of a package that I am maintaining other versions of. If I was Alon, I wouldn't want to do maintain both just cause you wanted me to. Well if you have read his past posts. He already stated he plans to leave that version in tree, and will maintain it. http://marc.info/?l=gentoo-devm=119746280128793w=2 gpg-1.X series will be available as long as upstream maintain it. It's just a matter of the two being able to co-exist. Not maintained. Nothing I have seen so far says anything about 1.x versions being removed and not maintained. We are just talking slots. It increases maintenance load and work he has to do and since he's a volunteer it's all about scratching his personal itch, since this doesn't for him.. why should he do it. Clearly it gives you an itch, so setup up and offer to help maintain. This is not a maintenance issue. Just a slotting issue. I would slot, but he would likely reverse my changes. I have no interest in a tug and war co-maintenance of a package. Plus Alon does seem to be doing good work. It's just the stubbornness over slots I don't understand at all. So there is little for me to contribute or do. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI placement
On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote: * Eclasses may not set EAPI. * Eclasses may not assume a particular EAPI. I disagree here. It would be annoying and possibly even hindering in future not being able to use higher EAPI features in eclasses. Point is the eclass has to check, if the author of an ebuild sets another EAPI and throw an error, in this case. The most basic issue, which we didn't even discuss yet, afaik, is how to make every developer aware which feature belongs to which EAPI. I freely admit, I do not know that. Is there a list somewhere? EAPI issues may lead to a lot of confusion and eclass bloat, especially since we still can't remove stale eclasses afaik. Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI placement
On Dec 12, 2007 11:14 PM, Carsten Lohrke [EMAIL PROTECTED] wrote: On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote: * Eclasses may not set EAPI. * Eclasses may not assume a particular EAPI. I disagree here. It would be annoying and possibly even hindering in future not being able to use higher EAPI features in eclasses. Point is the eclass has to check, if the author of an ebuild sets another EAPI and throw an error, in this case. Nobody said that eclasses can't use new features. Just that they cannot _set_ EAPI or assume they are working with any EAPI. But an eclass can check which EAPI is set in the environment (that's which EAPI the ebuild set) and act accordingly, using features available on that EAPI. The most basic issue, which we didn't even discuss yet, afaik, is how to make every developer aware which feature belongs to which EAPI. I freely admit, I do not know that. Is there a list somewhere? EAPIs are defined in PMS [1] although I don't find an officla copy at gentoo.org (only the one in dev.g.o/~spb). EAPI issues may lead to a lot of confusion and eclass bloat, especially since we still can't remove stale eclasses afaik. Yep, that issue should be addresses as it is in paludis and pkgcore. [1] http://www.gentoo.org/proj/en/qa/pms.xml -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Wed, 12 Dec 2007 23:14:24 +0100 Carsten Lohrke [EMAIL PROTECTED] wrote: I disagree here. It would be annoying and possibly even hindering in future not being able to use higher EAPI features in eclasses. Point is the eclass has to check, if the author of an ebuild sets another EAPI and throw an error, in this case. There is no way for an eclass to throw an error. Nor, with the current way Portage implements EAPI, is there a way to add such a way. The most basic issue, which we didn't even discuss yet, afaik, is how to make every developer aware which feature belongs to which EAPI. I freely admit, I do not know that. Is there a list somewhere? It's in PMS. svn co http://svn.repogirl.net/pms for a copy. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI placement
On Tue, 11 Dec 2007 20:00:51 -0500
Doug Klima [EMAIL PROTECTED] wrote:
When you could simply have $pkg_manager execute an eclass as 1
EAPI, another eclass as another and the ebuild as a third EAPI and
simplify it for the eclass maintenance.
Which doesn't work at all. Simple example would be the introduction of
new phases, e.g. src_configure with EAPI=2:
foo.eclass:
EAPI=2
setup_env {
# do some stuff that differs betwwen EAPI-1 and EAPI-2
}
src_configure {
econf --some-special-eclass-option
}
bar.ebuild:
inherit foo
EAPI=1
setup_env
# no src_* functions defined
Now should the package manager execute src_configure or not? And that's
assuming we actually track all values of EAPI and their origin as well
as the origin of all functions/variables in the current environment.
Or should setup_env be executed with EAPI=1 (as it's called in the
ebuild) or EAPI=2 (as it's defined in the eclass)? There are no real
answers to those problems.
Marius
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Wed, Dec 12, 2007 at 10:03:56AM -0500, William L. Thomson Jr. wrote:
On Wed, 2007-12-12 at 14:30 +0200, Alon Bar-Lev wrote:
Slotting makes logic if there is some advantage of having both slots
installed at the same machine,
Guess it's never been clear to you in upstream announcement that gnupg-1
BENEFITS from gnupg-2 co-existing. Again go back and read the
announcement.
as gnupg-2 does all gnupg-1 does,
It does NOT, do a comparison of command line args.
See the attached diff between the argument parsing.
I warned you last time, that it wasn't commandline argumnents, but
configure file arguments. Per bug
http://bugs.gentoo.org/show_bug.cgi?id=159505, upstream has decreed that
nobody should use 'gpg-agent-info' in the configuration file, and
instead, should use either the --gpg-agent-info argument to gpg, or set
the GPG_AGENT_INFO environment variable.
Upstream Seahorse did get this resolved, per bug
http://bugs.gentoo.org/show_bug.cgi?id=164523, which is why GPG2 can go
stable now. Evolution and Thunderbird resolved their issues as well,
which were much less of a problem, as they only used GPG - not tried to
be a gpg-agent replacement like Seahorse.
there
is no point in slotting, forcing users to mess with eselect in order
to resolve the dependency of other packages with gnupg.
You keep bringing up eselect when there is NO need. Apps that are
designed for gnupg2 call gpg2 or link to the -2 version of the .so.
Done, and NO need for eselect. That BS has flown, been sold, or bought
for over a year now :)
That is bull, and as the crypto herd, we raised it before.
Try again with some more BS reasons not to slot :)
The most common way for applications to use GPG is via libgpgme
http://tinderbox.dev.gentoo.org/misc/rindex/app-crypt/gpgme for the
large list, KDE is there, so is GNOME [via seahorse]). It's a sucky
library IMO, but it's widely used. The core problem with it, is that it
execs the GPG binary, and that the location binary chosen for execution
is compiled into the library at build-time.
That is, if you have /usr/bin/gpg and /usr/bin/gpg2, you can compile it
against exactly one of them. If you have it built against GPG1, and
happen to need some functionality that is only present in GPG2 (eg
SHA-224 message hashes), you need to recompile gpgme to use gpg2, but
then you run into trouble with your complaint.
Or you could have an eselect module for each non-root user to choose
which GPG they wanted, or you could just avoid the entire issue and
recommend that everybody upgrades to GPG2.
You can always mask =gnupg-2 if you want the 1.X series on embedded
devices.
Which I have done for my desktop use for 6 months now. Masking to use a
current version of a package version that will continue to be maintained
in the same slot as a newer version is quite stupid. IMHO.
I think that GnuPG is going to end up with the following case:
- Pick ANY _one_ supported major version of GnuPG, and stick with it.
We used to support 1.2 and 1.4 (not slotted, just one-of). Upstream
GnuPG stopped 1.2 support, and now we support 1.4 and 2.0.
The attached diff shows the difference in the command-line options
supported by GPG-1.4.x vs. GPG-2.0.x.
- The smartcard reader stuff CCID/CT/*SC has moved to be external.
- The list-ownertrust, pipemode, shm-coproc were 1.2 features, marked as
deprecated in 1.4, and removed in 2.0.
You'll be fine until some GPG-using package wants a feature specific to
GPG2, and then you can either complain at the authors of that app, or
suck it up and upgrade.
--
Robin Hugh Johnson
Gentoo Linux Developer Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
This is a comparision between the commandline arguments supported by GnuPG
v1.4.7 and v2.0.7. It was produced by grabbing the 'ARGPARSE_OPTS opts' block
from the g10/gpg.c file in each tarball, joining lines where a single option
spanned multiple lines, then sorting and diffing.
Created-by: Robin H. Johnson [EMAIL PROTECTED]
--- gpg1-opts 2007-12-12 18:38:40.0 -0800
+++ gpg2-opts 2007-12-12 18:38:44.0 -0800
@@ -50,7 +50,6 @@
{ aListKeys, list-key, 0, @ }, /* alias */
{ aListKeys, list-keys, 256, N_(list keys)},
{ aListKeys, list-public-keys, 256, @ },
-{ aListOwnerTrust, list-ownertrust, 256, @}, /* deprecated */
{ aListPackets, list-packets,256, @},
{ aListSecretKeys, list-secret-keys, 256, N_(list secret keys)},
{ aListSigs, list-sig, 0, @ }, /* alias */
@@ -58,7 +57,6 @@
{ aListTrustDB, list-trustdb,0 , @},
/* { aListTrustPath, list-trust-path,0, @}, */
{ aLSignKey, lsign-key ,256, N_(sign a key locally)},
-{ aPipeMode, pipemode, 0, @ },
{ aPrimegen, gen-prime , 256, @ },
{ aPrintMD, print-md , 256, N_(|algo [files]|print message digests)},
{ aPrintMDs, print-mds , 256, @}, /* old */
@@ -67,6 +65,7 @@
{ aRefreshKeys, refresh-keys, 256, N_(update all keys from a
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Wed, 2007-12-12 at 20:46 -0800, Robin H. Johnson wrote: See the attached diff between the argument parsing. Ok, thank you I warned you last time, that it wasn't commandline argumnents, but configure file arguments. Part of that was going from the wrapper to replicate missing commands or functionality attached to one of the bugs that you had contributed to creating. Granted it as a band aid at the time, and has expired for the most part. http://bugs.gentoo.org/attachment.cgi?id=113289 Per bug http://bugs.gentoo.org/show_bug.cgi?id=159505, upstream has decreed that nobody should use 'gpg-agent-info' in the configuration file, and instead, should use either the --gpg-agent-info argument to gpg, or set the GPG_AGENT_INFO environment variable. Upstream Seahorse did get this resolved, I tested out working solutions before upstream acted on this. I did give up on it long ago though. per bug http://bugs.gentoo.org/show_bug.cgi?id=164523 Which is a dup of the one you posted above. Both with a TON of comments from me :) In my suffering days. , which is why GPG2 can go stable now. Well I still need to do my own testing. Given that I have used seahorse daily for 1.5 years now. I will give it a go, but I am not expecting to do anything crazy like before to get it working. Mostly gave up on trying and thus allowed bugs to be closed out of ignoring the matter till stabilization time :) Evolution and Thunderbird resolved their issues as well, which were much less of a problem, as they only used GPG - not tried to be a gpg-agent replacement like Seahorse. Notice how I am not bring up Seahorse at all. The relation there has kinda convoluted the entire situation wrt to gnupg-2. That being said I do still have gnupg-2 masked on my system. I had seahorse working at times in the past with gnupg-2. Per both bugs you posted :) It likely works now, but not as easily or flawlessly as it does with gnupg-1. Thus it's been masked for months now. As I got sick of all the HOURS/days wasted on trial and error there. Why do I use Seahorse or gnupg/gpg at all? Well it's a Gentoo requirement :) I have to sign my emails, so wasn't really my choice to start using. Granted could have use Tbird with Enigmail, but been using Evo for years. But all the Seahorse stuff is moot now, and I was hoping to be kept out of this conversation. Because it's pretty irrelevant. The most common way for applications to use GPG is via libgpgme http://tinderbox.dev.gentoo.org/misc/rindex/app-crypt/gpgme for the large list, KDE is there, so is GNOME [via seahorse]). It's a sucky library IMO, but it's widely used. The core problem with it, is that it execs the GPG binary, and that the location binary chosen for execution is compiled into the library at build-time. And what upstream maintains gpgme, and what is their relation to gnupg? Even seahorse tracked it's problems down to that or at least blamed it on that. Seems like more work should be done with gnupg and gpgme, since they are both gnupg.org projects. Verses other things using gpgme or etc. Which are external projects. That is, if you have /usr/bin/gpg and /usr/bin/gpg2, you can compile it against exactly one of them. If you have it built against GPG1, and happen to need some functionality that is only present in GPG2 (eg SHA-224 message hashes), you need to recompile gpgme to use gpg2, but then you run into trouble with your complaint. Um well from what I have seen on other distros is exactly that. Apps will link against one or the other. Based on how gnupg compiles things normally, and which version a package deps on. Gnupg-2 build system spits out gpg2, not gpg. We are making gpg there via a symlink. So any other project using gnupg, would likely expect to see gpg2 and -2.so if it were to use 2.x. Per upstream no? Or you could have an eselect module for each non-root user to choose which GPG they wanted, or you could just avoid the entire issue and recommend that everybody upgrades to GPG2. Seem like the choice on which gpg to use is a upstream choice per project. I guess you could take it one step further with eselect and giving users a choice there. But that's not 100% necessary. Again if they have a problem with a package deping on a gnupg 1.x verses gnupg 2.x. They can take the matter up with upstream or etc. Obviously less of an issue now, as it was a year ago. But this type of thought process is what held gnupg-2 from going stable on Gentoo for over a year after first release. I think that GnuPG is going to end up with the following case: - Pick ANY _one_ supported major version of GnuPG, and stick with it. We used to support 1.2 and 1.4 (not slotted, just one-of). Upstream GnuPG stopped 1.2 support, and now we support 1.4 and 2.0. Yes, but unlike 1.2, and 1.4. Upstream has designed 1.x and 2.0.x to be able to co-exist. I fail to see why that doesn't work for us on Gentoo. When it works on all others. I get your points mentioned
