[gentoo-user] Q on portage's rational to re-emerge packages

[gentoo-user] Q on portage's rational to re-emerge packages

[Helmut Jarausch]

Hi,
would anybody please be so kind to explain to me the rational used by  
portage to re-emerge
some packages.

I've installed portage 2.2.7 and when I try to emerge, say,    
app-shells/zsh-completions
it re-emerges (emerge -vp shows  'rR') several packages including,  
i.e., app-office/libreoffice

I can't imaging libreoffice depends in any way on zsh-completions.

So, what's going on?

(and rebuilding libreoffice isn't just fun)

Many thanks,
Helmut.

Re: [gentoo-user] Q on portage's rational to re-emerge packages

[Alan McKinnon]

On 27/09/2013 10:24, Helmut Jarausch wrote:
> Hi,
> would anybody please be so kind to explain to me the rational used by
> portage to re-emerge
> some packages.
> 
> I've installed portage 2.2.7 and when I try to emerge, say,  
> app-shells/zsh-completions
> it re-emerges (emerge -vp shows  'rR') several packages including, i.e.,
> app-office/libreoffice
> 
> I can't imaging libreoffice depends in any way on zsh-completions.
> 
> So, what's going on?
> 
> (and rebuilding libreoffice isn't just fun)
> 
> Many thanks,
> Helmut.


You didn't supply any output or any details about your system, so your
question can't be properly answered. I can make a guess, so from the man
page:

              r   reinstall (forced for some reason, possibly due to
slot or sub-slot)
              R   replacing (remerging same version)


I'd guess libreoffice needs to be rebuilt and is triggered by a sub-slot
(in the old days you would have had to run revdep-rebuild or emerge
@preserved-rebuild to find this)

I imagine this is in no way related to zsh-completions, that just
happens to be on the command line. It's related to running emerge.

If you require a better answer, please provide proper emerge output.
Rage questions don't usually lead to correct explanations


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Q on portage's rational to re-emerge packages

[Helmut Jarausch]

On 09/27/2013 11:09:11 AM, Alan McKinnon wrote:
> On 27/09/2013 10:24, Helmut Jarausch wrote:
> > Hi,
> > would anybody please be so kind to explain to me the rational used  
> by
> > portage to re-emerge
> > some packages.
> >
> > I've installed portage 2.2.7 and when I try to emerge, say,
> > app-shells/zsh-completions
> > it re-emerges (emerge -vp shows  'rR') several packages including,  
> i.e.,
> > app-office/libreoffice
> >
> > I can't imaging libreoffice depends in any way on zsh-completions.
> >
> > So, what's going on?
> >
> > (and rebuilding libreoffice isn't just fun)
> >
> > Many thanks,
> > Helmut.
> 
> 
> You didn't supply any output or any details about your system, so your
> question can't be properly answered. I can make a guess, so from the  
> man
> page:
> 
>               r   reinstall (forced for some reason, possibly due to
> slot or sub-slot)
>               R   replacing (remerging same version)
> 
> 
> I'd guess libreoffice needs to be rebuilt and is triggered by a  
> sub-slot
> (in the old days you would have had to run revdep-rebuild or emerge
> @preserved-rebuild to find this)
> 
> I imagine this is in no way related to zsh-completions, that just
> happens to be on the command line. It's related to running emerge.
> 
> If you require a better answer, please provide proper emerge output.
> Rage questions don't usually lead to correct explanations
> 
> 
> --
> Alan McKinnon
> alan.mckinnon@gmail.com
> 
> 

Here is a full example:
emerge -auv1 app-shells/zsh-completions

These are the packages that would be merged, in order:

Calculating dependencies - * Digest verification failed:
  * /LOCAL/local/portage/dev-python/wxpython/wxpython-9999.ebuild
  * Reason: Filesize does not match recorded size
  * Got: 4166
  * Expected: 4167
... done!
[ebuild  rR    ] dev-python/setuptools-1.1.6  PYTHON_TARGETS="python2_7  
python3_3 -pypy2_0 -python2_6 -python3_2" 0 kB
[ebuild  rR    ] dev-python/sip-4.15.2:0/10  USE="-debug -doc"  
PYTHON_TARGETS="python2_7 python3_3 -python2_6 -python3_2" 0 kB
[ebuild  rR    ] dev-python/pyopenssl-0.13.1  USE="-doc"  
PYTHON_TARGETS="python2_7 python3_3 -pypy2_0 -python2_6 -python3_2" 0 kB
[ebuild  rR    ] dev-python/pmw-2.0.0-r2:py3  USE="-doc -examples  
{-test}" PYTHON_TARGETS="python3_3 -python3_2" 0 kB
[ebuild  rR    ] app-portage/gentoolkit-0.3.0.8-r1   
PYTHON_TARGETS="python2_7 python3_3 -pypy2_0 -python2_6 -python3_2" 0 kB
[ebuild  rR    ] dev-python/pytz-2013d  PYTHON_TARGETS="python2_7  
python3_3 -pypy2_0 -python2_6 -python3_2" 0 kB
[ebuild  rR    ] dev-python/paramiko-1.11.0  USE="-doc -examples"  
PYTHON_TARGETS="python2_7 -python2_6" 0 kB
[ebuild  rR    ] dev-python/numpydoc-0.4-r1  USE="{-test}"  
PYTHON_TARGETS="python2_7 -python2_6" 0 kB
[ebuild  rR    ] dev-python/PyQt4-4.10.3  USE="X dbus declarative help  
kde opengl script sql svg webkit -debug -doc -examples -multimedia  
-phonon -scripttools -xmlpatterns" PYTHON_TARGETS="python2_7 python3_3  
-python2_6 -python3_2" 0 kB
[ebuild     U  ] app-shells/zsh-completions-0.10.0::sunrise  
[0.8.0::sunrise] 145 kB
[ebuild  rR    ] app-office/libreoffice-4.1.2.2  USE="bluetooth  
branding cups dbus gnome gtk java kde opengl vba webdav (-aqua) -debug  
-eds -gstreamer -gtk3 -jemalloc -mysql -odk -postgres -telepathy  
{-test}" LIBREOFFICE_EXTENSIONS="presenter-minimizer -nlpsolver  
-scripting-beanshell -scripting-javascript -wiki-publisher"  
PYTHON_SINGLE_TARGET="python2_7 -python3_3" PYTHON_TARGETS="python2_7  
python3_3" 0 kB

Total: 11 packages (1 upgrade, 10 reinstalls), Size of downloads: 145 kB


Does portage keep a "todo list" anywhere?

Thanks,
Helmut.

[gentoo-user] Re: Q on portage's rational to re-emerge packages

[Markus Trippelsdorf]

On 2013.09.27 at 10:24 +0200, Helmut Jarausch wrote:
> Hi,
> would anybody please be so kind to explain to me the rational used by  
> portage to re-emerge
> some packages.
> 
> I've installed portage 2.2.7 and when I try to emerge, say,    
> app-shells/zsh-completions
> it re-emerges (emerge -vp shows  'rR') several packages including,  
> i.e., app-office/libreoffice
> 
> I can't imaging libreoffice depends in any way on zsh-completions.
> 
> So, what's going on?

It's fallout from dev-python/python-exec-2.0...
Maybe Michał can explain why it's necessary to rebuild libreoffice.


-- 
Markus

Re: [gentoo-user] Q on portage's rational to re-emerge packages

[Hinnerk van Bruinehsen]

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

On Fri, Sep 27, 2013 at 11:28:43AM +0200, Helmut Jarausch wrote:
> <SNIP>
>
> Here is a full example:
> emerge -auv1 app-shells/zsh-completions
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies - * Digest verification failed:
>   * /LOCAL/local/portage/dev-python/wxpython/wxpython-9999.ebuild
>   * Reason: Filesize does not match recorded size
>   * Got: 4166
>   * Expected: 4167
> ... done!
> [ebuild  rR    ] dev-python/setuptools-1.1.6  PYTHON_TARGETS="python2_7
> python3_3 -pypy2_0 -python2_6 -python3_2" 0 kB
> [ebuild  rR    ] dev-python/sip-4.15.2:0/10  USE="-debug -doc"
> PYTHON_TARGETS="python2_7 python3_3 -python2_6 -python3_2" 0 kB
> [ebuild  rR    ] dev-python/pyopenssl-0.13.1  USE="-doc"
> PYTHON_TARGETS="python2_7 python3_3 -pypy2_0 -python2_6 -python3_2" 0 kB
> [ebuild  rR    ] dev-python/pmw-2.0.0-r2:py3  USE="-doc -examples
> {-test}" PYTHON_TARGETS="python3_3 -python3_2" 0 kB
> [ebuild  rR    ] app-portage/gentoolkit-0.3.0.8-r1
> PYTHON_TARGETS="python2_7 python3_3 -pypy2_0 -python2_6 -python3_2" 0 kB
> [ebuild  rR    ] dev-python/pytz-2013d  PYTHON_TARGETS="python2_7
> python3_3 -pypy2_0 -python2_6 -python3_2" 0 kB
> [ebuild  rR    ] dev-python/paramiko-1.11.0  USE="-doc -examples"
> PYTHON_TARGETS="python2_7 -python2_6" 0 kB
> [ebuild  rR    ] dev-python/numpydoc-0.4-r1  USE="{-test}"
> PYTHON_TARGETS="python2_7 -python2_6" 0 kB
> [ebuild  rR    ] dev-python/PyQt4-4.10.3  USE="X dbus declarative help
> kde opengl script sql svg webkit -debug -doc -examples -multimedia
> -phonon -scripttools -xmlpatterns" PYTHON_TARGETS="python2_7 python3_3
> -python2_6 -python3_2" 0 kB
> [ebuild     U  ] app-shells/zsh-completions-0.10.0::sunrise
> [0.8.0::sunrise] 145 kB
> [ebuild  rR    ] app-office/libreoffice-4.1.2.2  USE="bluetooth
> branding cups dbus gnome gtk java kde opengl vba webdav (-aqua) -debug
> -eds -gstreamer -gtk3 -jemalloc -mysql -odk -postgres -telepathy
> {-test}" LIBREOFFICE_EXTENSIONS="presenter-minimizer -nlpsolver
> -scripting-beanshell -scripting-javascript -wiki-publisher"
> PYTHON_SINGLE_TARGET="python2_7 -python3_3" PYTHON_TARGETS="python2_7
> python3_3" 0 kB
>
> Total: 11 packages (1 upgrade, 10 reinstalls), Size of downloads: 145 kB
>
>
> Does portage keep a "todo list" anywhere?


Hello Helmut,

you are encountering a relatively new feature of portage that is supposed to
make revdep-rebuild and emerge @preserve-rebuild obsolete.
The logic is, that if you update a package, other packages depending on this
package will automatically rebuild to prevent breakage.
It seems that in your case portage "thinks" that one of that packages depends
on zsh-completion and pulls that in for rebuild which in turn, most likely via
setuptools or PyQt4  pulls libreoffice to rebuild.

Because python is interpreted my guess is, that this rebuild would be
unnecessary. You can try to figure out the package via equery d <atom>,
starting with zsh-completion itself.

It may be possible that you can "dodge" the rebuild by emergeing zsh-completion
with the --nodeps option.

WKR
Hinnerk

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Q on portage's rational to re-emerge packages

[Philip Webb]

130927 Hinnerk van Bruinehsen wrote:
> you are encountering a relatively new feature of portage
> that is supposed to make revdep-rebuild & emerge @preserve-rebuild obsolete.
> The logic is, that if you update a package, other packages
> depending on this package will automatically rebuild to prevent breakage.
> It seems that in your case portage "thinks" that one of that packages
> depends on zsh-completion and pulls that in for rebuild,
> which in turn, most likely via setuptools or PyQt4,
> pulls libreoffice to rebuild.

I have found sometimes that Portage wants to remerge LO or similar,
but in fact the existing installed version continues to work regardless.
Try remerging the other pkgs first & see if LO still functions as usual ;
only if it doesn't do you need to remerge it.

HTH

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] Q on portage's rational to re-emerge packages

[Neil Bothwick]

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

On Fri, 27 Sep 2013 07:18:08 -0400, Philip Webb wrote:

> I have found sometimes that Portage wants to remerge LO or similar,
> but in fact the existing installed version continues to work regardless.

That's because you aren't using the broken bits. But that's fine as long
as it continues to work for you. I prefer to let the re-emerge go ahead,
I don't want it to stop working when I really need it and don't have the
time to rebuild it.


-- 
Neil Bothwick

I'm not anti-social, I'm just not user friendly

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Q on portage's rational to re-emerge packages

[Bruce Hill]

On Fri, Sep 27, 2013 at 12:38:44PM +0200, Markus Trippelsdorf wrote:
> On 2013.09.27 at 10:24 +0200, Helmut Jarausch wrote:
> > Hi,
> > would anybody please be so kind to explain to me the rational used by  
> > portage to re-emerge
> > some packages.
> > 
> > I've installed portage 2.2.7 and when I try to emerge, say,    
> > app-shells/zsh-completions
> > it re-emerges (emerge -vp shows  'rR') several packages including,  
> > i.e., app-office/libreoffice
> > 
> > I can't imaging libreoffice depends in any way on zsh-completions.
> > 
> > So, what's going on?
> 
> It's fallout from dev-python/python-exec-2.0...
> Maybe Michał can explain why it's necessary to rebuild libreoffice.

I've had plenty of grief over python-exec-0.3.1 getting depcleaned a couple
days ago. Rebuilding each pkg effected works, but what about the ones you
miss? Such as, no mail this morning... getmail stopped working.

I've just now "re-emerge python-exec:0" and will live with that until Michał
gets this fixed.

Should we report here: https://bitbucket.org/mgorny/python-exec/issues/
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Q on portage's rational to re-emerge packages

[Alan McKinnon]

On 27/09/2013 13:18, Philip Webb wrote:
> 130927 Hinnerk van Bruinehsen wrote:
>> you are encountering a relatively new feature of portage
>> that is supposed to make revdep-rebuild & emerge @preserve-rebuild obsolete.
>> The logic is, that if you update a package, other packages
>> depending on this package will automatically rebuild to prevent breakage.
>> It seems that in your case portage "thinks" that one of that packages
>> depends on zsh-completion and pulls that in for rebuild,
>> which in turn, most likely via setuptools or PyQt4,
>> pulls libreoffice to rebuild.
> 
> I have found sometimes that Portage wants to remerge LO or similar,
> but in fact the existing installed version continues to work regardless.
> Try remerging the other pkgs first & see if LO still functions as usual ;
> only if it doesn't do you need to remerge it.


Also consider how portage "knows" to rebuild something. In truth, it
doesn't know and has no way to just find out. It has to rely on data
added to the ebuild, and that's where this new feature called sub-slots
comes in.

In a nutshell, it's a DEPEND in reverse. LO has this one for example:

        =dev-util/mdds-0.8*:=

That's a classic DEPEND, to install LO you must have mdds, so it gets
pulled in and built. From then on portage keeps mdds up to date and
knows it must use only version 0.8.something.

So far so goo. But what happens if mdds-0.8.1 introduces an API/ABI
change that breaks LO? Traditionally we had no way of dealing with this
in ebuilds and had to rely on revdep-rebuild and @preserved-rebuild,
both of which are ugly hacks (never mind that they work reliably).
Portage still had no way of knowing breakage would happen if it did it's
usual thing, so that's where subslots come in (the := notation)[1]

Basically, it say something like "LO DEPENDS on mdds, but also if the
installed version of mdds later changes, then LO needs to be rebuilt to
properly link against the new (and changed) version of mdds.

This only works right if the ebuild maintainer is on the ball, watches
Changelogs for the DEPENDS packages and put the proper metadata in the
ebuild. You can imagine how this can work out very very well when done
right, and if the maintainer makes a mistake (or doesn't clearly
understand how it works) it can cause many unneccessary rebuilds (but
not actually *break* stuff). Huge packages like LO with many
interconnected DEPENDS are always going to be the usual victim I'm afraid...

And then there's things that use poppler, boost, PyQT and pykde4 - a
similar effect is at work.

End result = your cpus will be kept nice and toasty warm doing lots of
compiles but actual breakage of the sort that led to revdep-rebuild
being developed should reduce dramatically. Some unneccessary rebuilds
are the price we pay for not having breakage.

In Helmut's specific case here, the cause seems to be python-exec. I
missed that one myself somehow so had no idea it was hanging around
biting folks.



[1] For clarity, I'll leave out explaining syntax here, that is
documented elsewhere.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Q on portage's rational to re-emerge packages

[Stefan G. Weichinger]

Am 28.09.2013 00:22, schrieb Alan McKinnon:

> This only works right if the ebuild maintainer is on the ball, watches
> Changelogs for the DEPENDS packages and put the proper metadata in the
> ebuild. You can imagine how this can work out very very well when done
> right, and if the maintainer makes a mistake (or doesn't clearly
> understand how it works) it can cause many unneccessary rebuilds (but
> not actually *break* stuff). Huge packages like LO with many
> interconnected DEPENDS are always going to be the usual victim I'm afraid...
> 
> And then there's things that use poppler, boost, PyQT and pykde4 - a
> similar effect is at work.
> 
> End result = your cpus will be kept nice and toasty warm doing lots of
> compiles but actual breakage of the sort that led to revdep-rebuild
> being developed should reduce dramatically. Some unneccessary rebuilds
> are the price we pay for not having breakage.
> 
> In Helmut's specific case here, the cause seems to be python-exec. I
> missed that one myself somehow so had no idea it was hanging around
> biting folks.


For the last few days my desktop machine always wants to rebuild tons of
stuff like LibreOffice and PyQt4 etc ...

And it doesn't get to an end ... right now I say "emerge -1 gcc" and it
starts to emerge 13 packages ... with LO rebuilt several times afaik.

What to do about this situation?

Thanks, Stefan

Re: [gentoo-user] Q on portage's rational to re-emerge packages

[Khumba]

On Tue, 08 Oct 2013 15:13:31 +0200
"Stefan G. Weichinger" <lists@xunil.at> wrote:

> Am 28.09.2013 00:22, schrieb Alan McKinnon:
> 
> > This only works right if the ebuild maintainer is on the ball, watches
> > Changelogs for the DEPENDS packages and put the proper metadata in the
> > ebuild. You can imagine how this can work out very very well when done
> > right, and if the maintainer makes a mistake (or doesn't clearly
> > understand how it works) it can cause many unneccessary rebuilds (but
> > not actually *break* stuff). Huge packages like LO with many
> > interconnected DEPENDS are always going to be the usual victim I'm afraid...
> > 
> > And then there's things that use poppler, boost, PyQT and pykde4 - a
> > similar effect is at work.
> > 
> > End result = your cpus will be kept nice and toasty warm doing lots of
> > compiles but actual breakage of the sort that led to revdep-rebuild
> > being developed should reduce dramatically. Some unneccessary rebuilds
> > are the price we pay for not having breakage.
> > 
> > In Helmut's specific case here, the cause seems to be python-exec. I
> > missed that one myself somehow so had no idea it was hanging around
> > biting folks.
> 
> 
> For the last few days my desktop machine always wants to rebuild tons of
> stuff like LibreOffice and PyQt4 etc ...
> 
> And it doesn't get to an end ... right now I say "emerge -1 gcc" and it
> starts to emerge 13 packages ... with LO rebuilt several times afaik.
> 
> What to do about this situation?
> 
> Thanks, Stefan
> 

EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"

in make.conf to disable slot operator rebuilds (and allow any
associated breakage).  Portage still seems to keep track of subslot
dependency rebuilds while this flag is enabled, so that you can remove
it later and rebuild anything Portage considers broken.

Cheers,
Khumba

Re: [gentoo-user] Q on portage's rational to re-emerge packages

[Stefan G. Weichinger]

Am 08.10.2013 16:04, schrieb Khumba:

> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"
> 
> in make.conf to disable slot operator rebuilds (and allow any
> associated breakage).  Portage still seems to keep track of subslot
> dependency rebuilds while this flag is enabled, so that you can remove
> it later and rebuild anything Portage considers broken.

Thanks for that hint ... gcc builds now fine (only 3 pkgs) ... I wonder
if we should already rebuild something like @system with gcc-4.8.1-r1
;-)  I assume, no .. (and it is OT for this thread, sorry).

S

Re: [gentoo-user] Q on portage's rational to re-emerge packages

[Markos Chandras]

On 09/27/2013 09:24 AM, Helmut Jarausch wrote:
> Hi,
> would anybody please be so kind to explain to me the rational used by
> portage to re-emerge
> some packages.
> 
> I've installed portage 2.2.7 and when I try to emerge, say,  
> app-shells/zsh-completions
> it re-emerges (emerge -vp shows  'rR') several packages including, i.e.,
> app-office/libreoffice
> 
> I can't imaging libreoffice depends in any way on zsh-completions.
> 
> So, what's going on?
> 
> (and rebuilding libreoffice isn't just fun)
> 
> Many thanks,
> Helmut.

Maybe https://bugs.gentoo.org/show_bug.cgi?id=486910 ?

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang