Re: [gentoo-user] Re: Portage getting slicker?

[Marc Joliet]

On Thursday 14 July 2016 14:43:54 Gevisz wrote:
> On Thu, 14 Jul 2016 09:52:41 +0200 Marc Joliet  wrote:
> > On Thursday 14 July 2016 08:17:19 Alan McKinnon wrote:
> > > -N is newuse, portage also considers packages whose USE has changed.
> > > -t is emptytree, portage also considers the entire tree and -u tells it
> > > to not remerge things that don't need updating.
> > 
> > Um, -e is --emptytree, no? -t is just --tree.  But yeah, according to his
> > first email, James did leave out -N the second time around ("emerge -uvDNp
> > world" vs. "emerge -uDtv @world").
> 
> Sorry for the interrupting a big gurus, but in my humble opinion
> the reason why there was no compilation while running emerge for
> the first time is the -p option (pretend).

I'm no guru, I was merely exploiting a rare opportunity to correct Alan ;-) .

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Portage getting slicker?

[Fernando Rodriguez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/13/2016 05:41 PM, James wrote:
> Alan McKinnon  gmail.com> writes:
> 
>>
>> On 13/07/2016 20:25, James wrote:

>>> So, today I ran a sync and upgrade to a gentoo workstation::
>>> emerge -uvDNp world
>>>
>>> These are the packages that would be merged, in order:
>>> Calculating dependencies... done!
>>> Total: 0 packages, Size of downloads: 0 KiB
>>> WARNING: One or more updates/rebuilds have been skipped due to a dependency
>>> conflict:
>>>
>>> media-libs/jasper:0
>>>
>>>(media-libs/jasper-1.900.1-r9:0/0::gentoo, ebuild scheduled for merge)
>>> conflicts with
>>>  media-libs/jasper:0/0=[abi_x86_32(-),abi_x86_64(-)] required by
>>> (x11-libs/gdk-pixbuf-2.32.3:2/2::gentoo, installed)
>>>
>>>  media-libs/jasper:=[abi_x86_32(-),abi_x86_64(-)] required by
>>> (x11-libs/gdk-pixbuf-2.32.3:2/2::gentoo, installed)
>>
>> This is not a blocker.
>>
>> Read the warning, it says an update or rebuild was skipped due to a 
>> dependency conflict. In your casejasper-1.900.1-r9 was not done due to 
>> gdk-pixbuf requirements. Presumably, what you already have keeps pixbuf 
>> happy
>>
>> Blockers in that output usually have "!!" annotations at the beginning.
> 
> Ah excellent point, but the build did not move forward with::
> ' emerge -uvDN world' either. With the --tree it did move forward with
> the build update. In the first attempt usually the packages to be built
> are listed, conflicts or blockers.
> 
> None of these 3 packages where listed in the first attempt to see 
> what needs to be built::
> Not 'sys-devel/llvm', nor 'sys-devel/clang', nor 'media-libs/mesa'.
> 
> 
> 
>> Emerging (1 of 3) sys-devel/llvm-3.7.1-r3::gentoo
> 
>>> I did nothing manual in between. Explanations?
>> portage is doing what's expected. You don't have -a in the command line 
>> and there's nothing stopping portage from moving forward with the build.
>> SO it moved forward with the build.
> 
> Yes, nothing to do with 'media-libs/jasper' nor 'gdk-pixbuf'. So I guess the
> --tree option got rid of the these (conflicts issues. My point is that this
> is remarkably better than how things worked in the past (but not certain
> when these enhancements were made).

The --tree command didn't get rid of them. Those packages that you where able
to build conflict with other packages that would have been considered with the
- --newuse flag. So the conflict is still there waiting to be resolved.

Maybe portage could've been a little smarter and determine on the first command
that yes there is a conflict but I can still build these 3 packages with what
you already have. Or maybe that's a bad idea because you may have to rebuild 
some of those packages once the conflict is resolved and all packages updated.

Maybe the 1st command should've given you a list of skipped packages. That would
make it way less confusing and easier to resolve the conflicts. It is especially
confusing because instinctively you would expect the results with --newuse to be
a superset of the results without it.


 
> Thanks for pointing out blockers vs conflicts...
> 
> James
> 
> 
> 
> 
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXh/zxAAoJEPbOFX/5UlwcsN0P/Rs3PbvPqBVtk5r/q9DdxFpi
ZKCNm+wktkEeCRnPqNaDNQBtyjNz9gbyOn+DFSycETQBejKJ2Stusc3Cdmins9c+
MEVW0yDLz/3moY0UtL7GlQ4uB4YxkILv3dQUIDkYuJ25dIUb3pJvfg456R3xiMG7
XdZqyYYROF5WYaOuiL+c4B6l2sgWRqBpFyEude7oM7az9fNi4O5LbiQTMx+lGG9E
ODZEBYmDBVnmTPh8yZFWCwymUauOzwgEKTThqlykh1xu96LWv2NzkRCEvnnmHtMU
0aydjxpfX/0zdxJjvHbDcyvgyKCbdy6e+baD5GdQQTZe9SjIjJvUvv4PQCRfYhbd
FyaI6lKkGmAw/ONzaMY2pDfuqDfyAk6j1htx9LugYLKWTignUhW4j4F51Fo6C9TS
zKIYk99Ne7ruV8h89HFUqRnGBewUw5rNC0ytOGKucOMy5b2Uef9C8lcikfl2Q0XR
C22oEOjC9pqbuv77l3oawWt0gyOJDIyOpzuFCob2aeEiTGV2Xbo8APKerIiaVT4o
NAxPeSsgtB3ZZv18QaIyUENBaV1U6pVnXe6UszXqo7AjBcKo7LGqSEJZLJKJRgqO
S34ucuXePXeDvXpwu4foF7FwY+EDgJQeVQ59aIjLMBZe6o+Q/4V7mKJFQOmeOwuU
U6GNi/spdojHipzExJiC
=MazA
-END PGP SIGNATURE-

Re: [gentoo-user] Re: Portage getting slicker?

[Franz Fellner]

On Thu, 14 Jul 2016 14:43:54 +0300, Gevisz  wrote:
> On Thu, 14 Jul 2016 09:52:41 +0200 Marc Joliet  wrote:
> 
> > On Thursday 14 July 2016 08:17:19 Alan McKinnon wrote:
> > > -N is newuse, portage also considers packages whose USE has changed.
> > > -t is emptytree, portage also considers the entire tree and -u tells it
> > > to not remerge things that don't need updating.  
> > 
> > Um, -e is --emptytree, no? -t is just --tree.  But yeah, according to his 
> > first email, James did leave out -N the second time around ("emerge -uvDNp 
> > world" vs. "emerge -uDtv @world").
> 
> Sorry for the interrupting a big gurus, but in my humble opinion
> the reason why there was no compilation while running emerge for
> the first time is the -p option (pretend). 

No, even without -p the first command wouldn't have done anything, because 
"Total: 0 packages".
There simple was nothing to do! The second command showed "3 Packages".

> 
> 
> 
> 
-- 

Re: [gentoo-user] Re: Portage getting slicker?

[Gevisz]

On Thu, 14 Jul 2016 09:52:41 +0200 Marc Joliet  wrote:

> On Thursday 14 July 2016 08:17:19 Alan McKinnon wrote:
> > -N is newuse, portage also considers packages whose USE has changed.
> > -t is emptytree, portage also considers the entire tree and -u tells it
> > to not remerge things that don't need updating.  
> 
> Um, -e is --emptytree, no? -t is just --tree.  But yeah, according to his 
> first email, James did leave out -N the second time around ("emerge -uvDNp 
> world" vs. "emerge -uDtv @world").

Sorry for the interrupting a big gurus, but in my humble opinion
the reason why there was no compilation while running emerge for
the first time is the -p option (pretend). 

Re: [gentoo-user] Re: Portage getting slicker?

[Marc Joliet]

On Thursday 14 July 2016 08:17:19 Alan McKinnon wrote:
> -N is newuse, portage also considers packages whose USE has changed.
> -t is emptytree, portage also considers the entire tree and -u tells it
> to not remerge things that don't need updating.

Um, -e is --emptytree, no? -t is just --tree.  But yeah, according to his 
first email, James did leave out -N the second time around ("emerge -uvDNp 
world" vs. "emerge -uDtv @world").

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Portage getting slicker?

[Alan McKinnon]

On 14/07/2016 04:03, James wrote:
>> It's unsurprising you got different behaviour
> true, but the -u was in both and a complete different set of 
> packages was considered, by portage, and only one was able to 
> move forward (note the -p was not in the second entry, despite
> my not including that detail).

without -N or -t, portage considers just the list of packages on the
command line.

-N is newuse, portage also considers packages whose USE has changed.
-t is emptytree, portage also considers the entire tree and -u tells it
to not remerge things that don't need updating.

The input set for those commands differs, so the output set might also
be different. Those two commands you ran are not guaranteed to produce
the same results (although the often will).


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

Re: [gentoo-user] Re: Portage getting slicker?

[Alan McKinnon]

On 13/07/2016 23:41, James wrote:

Alan McKinnon  gmail.com> writes:



On 13/07/2016 20:25, James wrote:



So, today I ran a sync and upgrade to a gentoo workstation::
emerge -uvDNp world

These are the packages that would be merged, in order:
Calculating dependencies... done!
Total: 0 packages, Size of downloads: 0 KiB
WARNING: One or more updates/rebuilds have been skipped due to a dependency
conflict:

media-libs/jasper:0

(media-libs/jasper-1.900.1-r9:0/0::gentoo, ebuild scheduled for merge)
conflicts with
  media-libs/jasper:0/0=[abi_x86_32(-),abi_x86_64(-)] required by
(x11-libs/gdk-pixbuf-2.32.3:2/2::gentoo, installed)

  media-libs/jasper:=[abi_x86_32(-),abi_x86_64(-)] required by
(x11-libs/gdk-pixbuf-2.32.3:2/2::gentoo, installed)


This is not a blocker.

Read the warning, it says an update or rebuild was skipped due to a
dependency conflict. In your casejasper-1.900.1-r9 was not done due to
gdk-pixbuf requirements. Presumably, what you already have keeps pixbuf
happy

Blockers in that output usually have "!!" annotations at the beginning.


Ah excellent point, but the build did not move forward with::
' emerge -uvDN world' either. With the --tree it did move forward with
the build update. In the first attempt usually the packages to be built
are listed, conflicts or blockers.


But you didn't run
emerge -uvDN world
You ran
emerge -uvDNp world
why won't move forward, ever



None of these 3 packages where listed in the first attempt to see
what needs to be built::
Not 'sys-devel/llvm', nor 'sys-devel/clang', nor 'media-libs/mesa'.




Emerging (1 of 3) sys-devel/llvm-3.7.1-r3::gentoo



I did nothing manual in between. Explanations?

portage is doing what's expected. You don't have -a in the command line
and there's nothing stopping portage from moving forward with the build.
SO it moved forward with the build.


Yes, nothing to do with 'media-libs/jasper' nor 'gdk-pixbuf'. So I guess the
--tree option got rid of the these (conflicts issues. My point is that this
is remarkably better than how things worked in the past (but not certain
when these enhancements were made).


But you introduced two significant changes in you command line
removed -N
added -t


It's unsurprising you got different behaviour