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] [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] [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] [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] [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] [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] [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
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Dec 9, 2007 9:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote: On 15:49 Sat 08 Dec , Alon Bar-Lev wrote: Hello, I want to make gnupg-2 stable. The problem is that gnupg-1.9 was slotted as slot 1.9 and made stable. So now we have two slots, slot 0 and slot 1.9. gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting should be used. As far as I see, there are two migration pathes I can use: 1. Mark gnupg-2 stable, as it blocks older versions, this results in forcing users to manually unmerge the gnugp-1.9 series, this is the quickest and simplest migration path. Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather than SLOT 1.9? he end result would be one slot... If I need to chose 1.9 or 0, I prefer the standard is to have slot 0. 2. Perform slot-move of slot 0 and slot 1.9 into slot 2, so migration will be smooth. The problem is that I need all archs to work with me in timely manner so that this will be possible. I have bug#194113 waiting for arm, mips, s390, sh, and this only for the dependencies. I can imagine this resulting in very weird issues, when you have two of the same package installed in the same slot. What? These are two versions If nobody else address this, I will chose the easy way - option#0. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 22:49 Tue 11 Dec , Alon Bar-Lev wrote: On Dec 9, 2007 9:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote: On 15:49 Sat 08 Dec , Alon Bar-Lev wrote: Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather than SLOT 1.9? he end result would be one slot... If I need to chose 1.9 or 0, I prefer the standard is to have slot 0. What happens to people who only have slot 1.9 installed and not slot 0, or vice versa? You might want to test a few different upgrade scenarios to see what portage does. 2. Perform slot-move of slot 0 and slot 1.9 into slot 2, so migration will be smooth. The problem is that I need all archs to work with me in timely manner so that this will be possible. I have bug#194113 waiting for arm, mips, s390, sh, and this only for the dependencies. I can imagine this resulting in very weird issues, when you have two of the same package installed in the same slot. What? These are two versions Right, but two versions are never supposed to be installed into the same slot. They are during upgrade/downgrade, but that's short-term. Some package managers could respond oddly. If you were going to go this route, it would again be worth testing in advance. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Sat, 2007-12-08 at 15:49 +0200, Alon Bar-Lev wrote: gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting should be used. Drop in according to YOU, which I have taken issue with since 1/1/07. Per last upstream release, and every one since 2.x was release, just as I have quoted and stated many times before. http://lists.gnupg.org/pipermail/gnupg-announce/2007q3/000259.html GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.6) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. 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 far as I see, there are two migration pathes I can use: There is a third you have refused for almost a year now. 1.x should remain slot 0, 2.x should be slot 2. http://bugs.gentoo.org/show_bug.cgi?id=159623 I also mentioned that if left unaddressed I would challenge this issue when it came time for stabilization. Which gnupg2 was release over a year ago now. Main reason that held it back so long was refusal to slot 2.x versions, in any slot other than 0. Just as 1.9 was slotted. Even if all technical issues with gnupg 2.x have been worked out. It is NOT a drop in replacement for 1.x. The two are different and DESIGNED to work together. We will effectively rob users of the choice of 1.x for what ever reasons and force 2.x on them. Which deviates from all other distros. Not to mention we symlink gpg - gpg2, and gpg2 does not implement all features of gpg, command line args. By default upstream spits out the binaries on build with different names, same thing with .so's and etc. So there isn't any conflict/collision problems. In fact just the opposite if one hits gpg expecting a gpg command feature set, and instead getting a gpg2 one. I have wasted weeks on this posting on comments on bugs. Brought up the issue here before. We have lost a year wrt to gnupg 2. I am all for moving forward and dropping legacy versions of packages from the tree. But this is not one IMHO. Last post on this topic, ever for me. It's WAY stupid at this point. The horse has been beaten to death, exhumed, killed again, re-exhumed, mummified, put on exhibit, taken down, killed again, and re-buried :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 12/12/07, Donnie Berkholz [EMAIL PROTECTED] wrote: On 22:49 Tue 11 Dec , Alon Bar-Lev wrote: On Dec 9, 2007 9:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote: On 15:49 Sat 08 Dec , Alon Bar-Lev wrote: Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather than SLOT 1.9? he end result would be one slot... If I need to chose 1.9 or 0, I prefer the standard is to have slot 0. What happens to people who only have slot 1.9 installed and not slot 0, or vice versa? You might want to test a few different upgrade scenarios to see what portage does. OK, I will try this. 2. Perform slot-move of slot 0 and slot 1.9 into slot 2, so migration will be smooth. The problem is that I need all archs to work with me in timely manner so that this will be possible. I have bug#194113 waiting for arm, mips, s390, sh, and this only for the dependencies. I can imagine this resulting in very weird issues, when you have two of the same package installed in the same slot. What? These are two versions Right, but two versions are never supposed to be installed into the same slot. They are during upgrade/downgrade, but that's short-term. Some package managers could respond oddly. If you were going to go this route, it would again be worth testing in advance. I don't understand... It works quite some time for many people. Alon. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 12/12/07, William L. Thomson Jr. [EMAIL PROTECTED] wrote: On Sat, 2007-12-08 at 15:49 +0200, Alon Bar-Lev wrote: gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting should be used. Drop in according to YOU, which I have taken issue with since 1/1/07. Per last upstream release, and every one since 2.x was release, just as I have quoted and stated many times before. http://lists.gnupg.org/pipermail/gnupg-announce/2007q3/000259.html GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.6) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. 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. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [RFC] gnupg-2 stable plans
Hello, I want to make gnupg-2 stable. The problem is that gnupg-1.9 was slotted as slot 1.9 and made stable. So now we have two slots, slot 0 and slot 1.9. gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting should be used. As far as I see, there are two migration pathes I can use: 1. Mark gnupg-2 stable, as it blocks older versions, this results in forcing users to manually unmerge the gnugp-1.9 series, this is the quickest and simplest migration path. 2. Perform slot-move of slot 0 and slot 1.9 into slot 2, so migration will be smooth. The problem is that I need all archs to work with me in timely manner so that this will be possible. I have bug#194113 waiting for arm, mips, s390, sh, and this only for the dependencies. Any thoughts? Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 15:49 Sat 08 Dec , Alon Bar-Lev wrote: Hello, I want to make gnupg-2 stable. The problem is that gnupg-1.9 was slotted as slot 1.9 and made stable. So now we have two slots, slot 0 and slot 1.9. gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting should be used. As far as I see, there are two migration pathes I can use: 1. Mark gnupg-2 stable, as it blocks older versions, this results in forcing users to manually unmerge the gnugp-1.9 series, this is the quickest and simplest migration path. Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather than SLOT 1.9? 2. Perform slot-move of slot 0 and slot 1.9 into slot 2, so migration will be smooth. The problem is that I need all archs to work with me in timely manner so that this will be possible. I have bug#194113 waiting for arm, mips, s390, sh, and this only for the dependencies. I can imagine this resulting in very weird issues, when you have two of the same package installed in the same slot. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
