subject:"Re\: \[gentoo\-user\] update world problem \(looks like slot confusion on my part\)"

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

2014-06-22 Thread gottlieb

On Sat, Jun 21 2014, Neil Bothwick wrote:

 On Fri, 20 Jun 2014 21:20:52 -0400, Rich Freeman wrote:

  The moral is always look for portage trying to downgrade packages and
  add the appropriate keyword entries when using this approach.
   
 
 The only issue with this is that you never get back to stable that way.

 You will, it just takes a few steps with the odd package. The situation
 only arises where a release is pulled before ever going stable,
 generally because testing did its job and found a problem. Most packages
 do not need this attention.

I see.  During my going stable period I had this occur a few times.
Some times I let portage downgrade other times and added the keyword
entries other times (for me the second case involved updating not adding
keyword entries)

This time I am being asked to add keyword entries.  I will follow your
advice and not consider downgrading to the highest stable version.

thanks for the advice.
allan

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

2014-06-21 Thread Neil Bothwick

On Fri, 20 Jun 2014 21:20:52 -0400, Rich Freeman wrote:

  The moral is always look for portage trying to downgrade packages and
  add the appropriate keyword entries when using this approach.
   
 
 The only issue with this is that you never get back to stable that way.

You will, it just takes a few steps with the odd package. The situation
only arises where a release is pulled before ever going stable,
generally because testing did its job and found a problem. Most packages
do not need this attention.


-- 
Neil Bothwick

Vital papers will demonstrate their vitality by moving to where you
can't find them.


signature.asc
Description: PGP signature

Re: [gentoo-user] update world problem (looks like slot confusion on my part)

2014-06-20 Thread Alan McKinnon

On 20/06/2014 00:22, gottl...@nyu.edu wrote:
On Thu, Jun 19 2014, Alan McKinnon wrote:

On 19/06/2014 21:17, gottl...@nyu.edu wrote:

There are a few more again with no parents Then comes one that I
can't understand

virtual/libintl:0

(virtual/libintl-0-r1::gentoo, ebuild scheduled for merge) pulled in by

=virtual/libintl-0-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
required by (net-libs/gnutls-3.3.4::gentoo, ebuild scheduled
for merge)

(virtual/libintl-0::gentoo, installed) pulled in by
=virtual/libintl-0 required by (net-analyzer/nmap-6.25::gentoo,
installed)
(and 31 more with the same problem)

This seems to say that nmap-6.25 requires specifically
virtual/libintl-0. But I went to net-analyzer/nmap-6.25.ebuild and the
only occurrence of libintl is
nls? ( virtual/libintl )
in RDEPEND

Why does this require specifically virtual/libintl-0 and not permit
virtual/libintl-0-r1?

It's not nmap doing it, it is gnutls. Look again at the first line (for
the -r1 version). Your gnutls is still ~arch and stable hasn't caught up
yet. Run this

emerge -1 gnutls

then continue with your regular world update.

In summary, when you get these weird blockers, always check if the
higher number version is being pulled in by something ~arch. Then
downgrade that offender manually.

I am trying to understand this but having difficulty. Perhaps the whole
problem is caused by later complaints from portage asking me to keyword
items.

I understand that gnutls-3.3.4 needs the -r1 version of
virtual/libintl-0. I don't understand why the other packages (nmap-6.25
and 31 others) are not happy with the -r1. Maybe this is just bad
wording on portage's part and the real problem is that the -r1 version is
keyworded and I am going stable without virtual/libintl in
package.accept-keywords.

I don't think that emerge -1 gnutls will help since it simply re-installs
the stable 2.12.23-r6.

Ah, I see what it is. libintl is being pulled in by gnutls, which is
being pulled in by something else (gnutls is scheduled for emerge). To
find out what that something is, use emerge with -t

These dependency chains can get long and complex, so best is usually to
look at the whole thing and see exactly what is going on. Most often you
have something in world that is keyworded, or the current version is
still ~arch

The question is why do I need the testing gnutls-3.3.4 ? The answer
according to portage (further down in the error messages) is

The following keyword changes are necessary to proceed:
(see package.accept_keywords in the portage(5) man page for more details)
# required by net-im/empathy-3.10.3
# required by gnome-base/gnome-core-apps-3.10.0
# required by gnome-base/gnome-3.10.0
# required by @selected
# required by @world (argument)
=net-libs/gnutls-3.3.4 ~amd64

However I currently have empathy-3.10.3 and the ebuild for stable
net-im/empathy-3.10.3 has in COMMON_DEPEND
=net-libs/gnutls-2.8.5:=

My current gnutls is 2.12.23-r6. Is the problem the := ? Anyway I
don't believe STABLE empathy should require TESTING gnutls.

You are right, that output doesn't make sense, possibly you have some
local config that is making it happen? Again -t will help sort out the
chain.

Something I find useful for these situations, take gnutls as an example:

grep -ir gnutls /etc/portage

finds everything I added to package.* and forgot about :-)
My make.conf is in /etc/portage, if yours is still in /etc/ you'll have
to grep that file as well

thanks again for helping and thanks in advance for clearing up my
confusion.

allan

--
Alan McKinnon
alan.mckin...@gmail.com