FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-12-2007, 11:30 AM
"Alon Bar-Lev"
 
Default gnupg-2 stable plans

On 12/12/07, Mart Raudsepp <leio@gentoo.org> 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.
--
gentoo-dev@gentoo.org mailing list
 
Old 12-12-2007, 02:03 PM
"William L. Thomson Jr."
 
Default 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
 
Old 12-12-2007, 02:08 PM
"William L. Thomson Jr."
 
Default gnupg-2 stable plans

On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote:
> On 12/12/07, Jan Kundrát <jkt@gentoo.org> 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
 
Old 12-12-2007, 02:17 PM
Jan Kundrát
 
Default gnupg-2 stable plans

Alon Bar-Lev wrote:
> On 12/12/07, Jan Kundrát <jkt@gentoo.org> 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
 
Old 12-12-2007, 02:55 PM
"Santiago M. Mola"
 
Default gnupg-2 stable plans

On Dec 12, 2007 4:08 PM, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
> On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote:
> > On 12/12/07, Jan Kundrát <jkt@gentoo.org> 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: cooldwind@gmail.com
 
Old 12-12-2007, 03:11 PM
Doug Klima
 
Default 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 <jkt@gentoo.org> 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.
--
gentoo-dev@gentoo.org mailing list
 
Old 12-12-2007, 03:51 PM
"William L. Thomson Jr."
 
Default 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-dev&m=119746280128793&w=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
 
Old 12-13-2007, 03:46 AM
"Robin H. Johnson"
 
Default 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 : robbat2@gentoo.org
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 <robbat2@gentoo.org>

--- gpg1-opts 2007-12-12 18:38:40.000000000 -0800
+++ gpg2-opts 2007-12-12 18:38:44.000000000 -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 keyserver")},
{ aSearchKeys, "search-keys" , 256, N_("search for keys on a key server") },
{ aSendKeys, "send-keys" , 256, N_("export keys to a key server") },
+ { aServer, "server", 256, N_("run in server mode")},
{ aSignKey, "sign-key" ,256, N_("sign a key")},
{ aSign, "sign", 256, N_("|[file]|make a signature")},
{ aStore, "store", 256, "@"},
@@ -74,6 +73,7 @@
{ aUpdateTrustDB, "update-trustdb",0 , N_("update the trust database")},
{ aVerifyFiles, "verify-files" , 256, "@" },
{ aVerify, "verify" , 256, N_("verify a signature")},
+ { oAgentProgram, "agent-program", 2 , "@" },
{ oAllowFreeformUID, "allow-freeform-uid", 0, "@" },
{ oAllowMultipleMessages, "allow-multiple-messages", 0, "@"},
{ oAllowMultisigVerification, "allow-multisig-verification", 0, "@"},
@@ -109,10 +109,9 @@
{ oCompressLevel, "compress-level", 1, "@" },
{ oCompress, NULL, 1, N_("|N|set compress level N (0 disables)") },
{ oCompressSigs, "compress-sigs",0, "@"},
- { octapiDriver, "ctapi-driver", 2, "@"},
{ oDebugAll, "debug-all" ,0, "@"},
- { oDebugCCIDDriver, "debug-ccid-driver", 0, "@"},
{ oDebug, "debug" ,4|16, "@"},
+ { oDebugLevel, "debug-level" ,2, "@"},
{ oDefaultComment, "default-comment", 0, "@" },
{ oDefaultKey, "default-key", 2, "@"},
{ oDefaultKeyserverURL, "default-keyserver-url", 2, "@"},
@@ -124,7 +123,6 @@
{ oDefRecipientSelf, "default-recipient-self", 0, "@"},
{ oDefSigExpire, "default-sig-expire", 2, "@"},
{ oDigestAlgo, "digest-algo", 2, "@"},
- { oDisableCCID, "disable-ccid", 0, "@"},
{ oDisableCipherAlgo, "disable-cipher-algo", 2, "@" },
{ oDisableDSA2, "disable-dsa2", 0, "@"},
{ oDisableMDC, "disable-mdc", 0, "@"},
@@ -172,7 +170,6 @@
{ oKeyring, "keyring", 2, "@"},
{ oKeyServer, "keyserver", 2, "@"},
{ oKeyServerOptions, "keyserver-options",2,"@"},
- { oKOption, NULL, 0, "@"},
{ oLCctype, "lc-ctype", 2, "@" },
{ oLCmessages, "lc-messages", 2, "@" },
{ oLimitCardInsertTries, "limit-card-insert-tries", 1, "@"},
@@ -185,7 +182,7 @@
{ oLockNever, "lock-never", 0, "@" },
{ oLockOnce, "lock-once", 0, "@" },
{ oLoggerFD, "logger-fd",1, "@" },
- { oLoggerFile, "logger-file",2, "@" },
+ { oLoggerFile, "log-file",2, "@" },
{ oMangleDosFilenames, "mangle-dos-filenames", 0, "@" },
{ oMarginalsNeeded, "marginals-needed", 1, "@"},
{ oMaxCertDepth, "max-cert-depth", 1, "@" },
@@ -257,7 +254,6 @@
{ oPasswdFile, "passphrase-file",2, "@" },
{ oPasswd, "passphrase",2, "@" },
{ oPasswdRepeat, "passphrase-repeat", 1, "@"},
- { opcscDriver, "pcsc-driver", 2, "@"},
{ oPersonalCipherPreferences, "personal-cipher-preferences", 2, "@"},
{ oPersonalCipherPreferences, "personal-cipher-prefs", 2, "@"},
{ oPersonalCompressPreferences, "personal-compress-preferences", 2, "@"},
@@ -271,9 +267,8 @@
{ oPhotoViewer, "photo-viewer", 2, "@" },
{ oPreservePermissions, "preserve-permissions", 0, "@"},
{ oPrimaryKeyring, "primary-keyring",2, "@" },
- { oQuickRandom, "quick-random", 0, "@"},
+ { oQuickRandom, "debug-quick-random", 0, "@"},
{ oQuiet, "quiet", 0, "@"},
- { oReaderPort, "reader-port", 2, "@"},
{ oRecipient, "recipient", 2, N_("|NAME|encrypt for NAME")},
{ oRecipient, "remote-user", 2, "@"}, /* old option name */
{ oRecipient, "user", 2, "@" },
@@ -283,7 +278,6 @@
{ oRFC1991, "rfc1991", 0, "@"},
{ oRFC2440, "rfc2440", 0, "@" },
{ oRFC2440Text, "rfc2440-text", 0, "@"},
- { oRunAsShmCP, "run-as-shm-coprocess", 4, "@" },
{ oS2KCipher, "s2k-cipher-algo", 2, "@"},
{ oS2KCount, "s2k-count", 1, "@"},
{ oS2KDigest, "s2k-digest-algo", 2, "@"},
 
Old 12-13-2007, 04:57 AM
"William L. Thomson Jr."
 
Default 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 above. But have
always had counters to them.

> 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.

Looked like there were one or two others, not sure if they are part of
the above or not? Or what they do either way

> You'll be fine until some GPG-using package wants a feature specific to
> GPG2,

Then the package deps should be updated to reflect the version of gpg it needs.

> and then you can either complain at the authors of that app

Sure like I/we had to do for seahorse. Which didn't happen over night,
and depgraph problems carried on for a bit (few months) in the mean
time.

> or suck it up and upgrade.

I tried to many times, and so did many others Much of that record is
the bugs you posted.

Also how does this address the embedded or server use issue? Not package
deps or technical issues. But uses our users might have or etc. Or how
does it address the issue that gnupg-1 can benefit from using gnupg-2's
gpg-agent for passphrase caching.

I thought I was pretty clear before when I said all technical issues had
been resolved. Short of how stabilization would be handled, and moving
from two slots back to a single.

This is purely about robing users of a choice. Deviating from upstream
design, and all other distros. Not to mention making things harder than
they need to be and slowing things down for year.

--
William L. Thomson Jr.
Gentoo/Java
 
Old 12-13-2007, 04:28 PM
"Alon Bar-Lev"
 
Default gnupg-2 stable plans

Hello,

I selected the blocker option, forcing users to unmerge gnupg-1.9.
Users that used only 1.9 slot, will be notified later by revbumping this slot.

I am truly sorry for bothering users, but this is the only way to push
this forward.

Thank you for your comments,
Alon Bar-Lev.

BTW: If someone what to step forward and maintain gnupg, I will be most happy!
But this derives maintaining all g10 Code GmbH software, as they are
closely related.
dev-libs/libgcrypt
dev-libs/libksba
dev-libs/libgpg-error
app-crypt/pinentry
dev-libs/libassuan
app-crypt/dirmngr
app-crypt/gpgme

And probably more.

On 12/8/07, Alon Bar-Lev <alonbl@gentoo.org> 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.
>
> 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.
>
--
gentoo-dev@gentoo.org mailing list
 

Thread Tools




All times are GMT. The time now is 05:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org