[gentoo-user] Portage getting slicker?

[gentoo-user] Portage getting slicker?

[James]

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

<end/snip>


OK, no big deal, except I next ran::
'emerge -uDtv @world'

BANG, it just started compiling as if no blokers?

Calculating dependencies... done!
[ebuild  rR    ] media-libs/mesa-11.0.6::gentoo  USE="classic dri3 egl
gallium gbm gles2 llvm nptl openmax udev vaapi vdpau xvmc -bindist -d3d9
-debug -gles1 -opencl -osmesa -pax_kernel -pic (-selinux) -wayland -xa"
ABI_X86="32 (64) (-x32)" VIDEO_CARDS="radeon radeonsi (-freedreno) -i915
-i965 -ilo -intel -nouveau -r100 -r200 -r300 -r600 -vmware" 7,103 KiB
[nomerge       ] sys-devel/llvm-3.7.1-r3:0/3.7.1::gentoo
[3.5.0:0/3.5::gentoo] USE="clang libffi ncurses python static-analyzer
-debug -doc -gold -libedit -lldb% -multitarget -ocaml {-test} -xml"
ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 (-pypy%)"
VIDEO_CARDS="radeon" 
[blocks b      ]  <=sys-devel/clang-3.7.1-r99 ("<=sys-devel/clang-3.7.1-r99"
is blocking sys-devel/llvm-3.7.1-r3)
[ebuild     U  ]   sys-devel/clang-3.7.1-r100:0/3.7::gentoo
[3.5.0-r100:0/3.5::gentoo] USE="python static-analyzer -debug -multitarget"
ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  r  U  ]    sys-devel/llvm-3.7.1-r3:0/3.7.1::gentoo
[3.5.0:0/3.5::gentoo] USE="clang libffi ncurses python static-analyzer
-debug -doc -gold -libedit -lldb% -multitarget -ocaml {-test} -xml"
ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 (-pypy%)"
VIDEO_CARDS="radeon" 24,610 KiB

Total: 3 packages (2 upgrades, 1 reinstall), Size of downloads: 31,713 KiB
Conflict: 1 block

The following packages are causing rebuilds:

  (sys-devel/llvm-3.7.1-r3:0/3.7.1::gentoo, ebuild scheduled for merge)
causes rebuilds for:
    (media-libs/mesa-11.0.6:0/0::gentoo, ebuild scheduled for merge)

>>> Verifying ebuild manifests
>>> Running pre-merge checks for sys-devel/llvm-3.7.1-r3
 * Checking for at least 2400 MiB disk space at
"/var/tmp/portage/sys-devel/llvm-3.7.1-r3/temp" ...                        
                                       [ ok ]
>>> Emerging (1 of 3) sys-devel/llvm-3.7.1-r3::gentoo


Now this is coooool....
I did nothing manual in between. Explanations?

James

Re: [gentoo-user] Portage getting slicker?

[Alan McKinnon]

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.


>
> <end/snip>
>
>
> OK, no big deal, except I next ran::
> 'emerge -uDtv @world'
>
> BANG, it just started compiling as if no blokers?
>
> Calculating dependencies... done!
> [ebuild  rR    ] media-libs/mesa-11.0.6::gentoo  USE="classic dri3 egl
> gallium gbm gles2 llvm nptl openmax udev vaapi vdpau xvmc -bindist -d3d9
> -debug -gles1 -opencl -osmesa -pax_kernel -pic (-selinux) -wayland -xa"
> ABI_X86="32 (64) (-x32)" VIDEO_CARDS="radeon radeonsi (-freedreno) -i915
> -i965 -ilo -intel -nouveau -r100 -r200 -r300 -r600 -vmware" 7,103 KiB
> [nomerge       ] sys-devel/llvm-3.7.1-r3:0/3.7.1::gentoo
> [3.5.0:0/3.5::gentoo] USE="clang libffi ncurses python static-analyzer
> -debug -doc -gold -libedit -lldb% -multitarget -ocaml {-test} -xml"
> ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 (-pypy%)"
> VIDEO_CARDS="radeon"
> [blocks b      ]  <=sys-devel/clang-3.7.1-r99 ("<=sys-devel/clang-3.7.1-r99"
> is blocking sys-devel/llvm-3.7.1-r3)
> [ebuild     U  ]   sys-devel/clang-3.7.1-r100:0/3.7::gentoo
> [3.5.0-r100:0/3.5::gentoo] USE="python static-analyzer -debug -multitarget"
> ABI_X86="(64) -32 (-x32)" 0 KiB
> [ebuild  r  U  ]    sys-devel/llvm-3.7.1-r3:0/3.7.1::gentoo
> [3.5.0:0/3.5::gentoo] USE="clang libffi ncurses python static-analyzer
> -debug -doc -gold -libedit -lldb% -multitarget -ocaml {-test} -xml"
> ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 (-pypy%)"
> VIDEO_CARDS="radeon" 24,610 KiB
>
> Total: 3 packages (2 upgrades, 1 reinstall), Size of downloads: 31,713 KiB
> Conflict: 1 block
>
> The following packages are causing rebuilds:
>
>    (sys-devel/llvm-3.7.1-r3:0/3.7.1::gentoo, ebuild scheduled for merge)
> causes rebuilds for:
>      (media-libs/mesa-11.0.6:0/0::gentoo, ebuild scheduled for merge)
>
>>>> Verifying ebuild manifests
>>>> Running pre-merge checks for sys-devel/llvm-3.7.1-r3
>   * Checking for at least 2400 MiB disk space at
> "/var/tmp/portage/sys-devel/llvm-3.7.1-r3/temp" ...
>                                         [ ok ]
>>>> Emerging (1 of 3) sys-devel/llvm-3.7.1-r3::gentoo
>
>
> Now this is coooool....
> 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.

[gentoo-user] Re: Portage getting slicker?

[James]

Alan McKinnon <alan.mckinnon <at> 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'.

<snip>

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

Thanks for pointing out blockers vs conflicts...

James

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

[Alan McKinnon]

On 13/07/2016 23:41, James wrote:
> Alan McKinnon <alan.mckinnon <at> 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'.
>
> <snip>
>
>>>>>> 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

[gentoo-user] Re: Portage getting slicker?

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:




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

Nope.

I ran 'emerge -uvDNp world'
and then 'emerge -uvDN world'
No point delineating that detail, or so I thought

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

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

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.mckinnon@gmail.com

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

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Gevisz]

On Thu, 14 Jul 2016 09:52:41 +0200 Marc Joliet <marcec@gmx.de> 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?

[Franz Fellner]

On Thu, 14 Jul 2016 14:43:54 +0300, Gevisz <gevisz@gmail.com> wrote:
> On Thu, 14 Jul 2016 09:52:41 +0200 Marc Joliet <marcec@gmx.de> 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".

> 
> 
> 
> 
-- 

[gentoo-user] Re: Portage getting slicker?

[James]

Franz Fellner <alpine.art.de <at> gmail.com> writes:


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

Exactly! Pointless minutia, unless someone has knowledge of how the code
has changed over the last few years, related to those flags that change.

emerge -uvDNp world
emerge -uvDN world
emerge -uDtv @world

For sure 'N' and 't' are the specific flags that cause the differences
in behavior.

 So it was a just a 'moral booster' and a general 'shout out' for those
devs. If I really cared, and I do not have time to (deeply) care about these
improvements, I'd go to github and look at the codes that have changed over
the last few years, specifically realted to those aforementioned flags.....
So if you look here::

https://wiki.gentoo.org/wiki/Project:Portage

You can see the dev listing for the 'dev-portage@gentoo.org' whom
collectively are doing an excellent job:: and that's my point.

hth,
James

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 <alan.mckinnon <at> 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'.
> 
> <snip>
> 
>>>>>> 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?

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On Thursday 14 July 2016 14:43:54 Gevisz wrote:
> On Thu, 14 Jul 2016 09:52:41 +0200 Marc Joliet <marcec@gmx.de> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]