[gentoo-user] updating ALL packages

[gentoo-user] updating ALL packages

[gottlieb]

My normal updating procedure is

EMERGE_DEFAULT_OPTS="--ask --deep --tree --verbose --jobs --load-average=5"
emerge --update --changed-use --keep-going  @world

I had mistakenly thought this would update all packages not at the
latest version (subject to package.accept_keywords, package.mask, ...).

I now realize that it only does this for the packages in world and then
follows the dependency tree.  So if package A in world is up to date, A
depends of B, and a new version of B appears, B will not be updated.

As a result eix-test-obsolete finds that I have packages installed that
are no longer in the database.

I could do 

emerge --update the-2-dozen-such-packages

Is that wise?

thanks,
allan

PS This system is in the midst of the multi-month bothwick "goingstable"
procedure.  I don't know if that is relevant to the decision.

Neil Bothwick wrote:
>
> You can generate the list with
>
> qlist -ICv | sed -e 's/^/~/' -e 's/-r[1-9]$//' \
>     >/etc/portage/package.accept_keywords/goingstable
>
> This allows revision updates, which is useful as they usually contain bug
> or security fixes, but doesn't allow any higher versions.
>
> Occasionally running eix-test-obsolete will let you know which entries
> have become redundant because stable has caught up with them.
>
> I recently used it to move a machine from testing to stable. The one
> caveat is that sometimes the testing version your have installed, and in
> package.accept_keywords, is removed from the tree so portage wants to
> downgrade to the latest stable version. You have the choice of letting
> this happen or unmasking a later testing version.

[ subsequently he recommended using the latter choice ]

[gentoo-user] Re: updating ALL packages

[gottlieb]

On Wed, Jul 23 2014, gottlieb@nyu.edu wrote:

> My normal updating procedure is
>
> EMERGE_DEFAULT_OPTS="--ask --deep --tree --verbose --jobs --load-average=5"
> emerge --update --changed-use --keep-going  @world
>
> I had mistakenly thought this would update all packages not at the
> latest version (subject to package.accept_keywords, package.mask, ...).
>
> I now realize that it only does this for the packages in world and then
> follows the dependency tree.  So if package A in world is up to date, A
> depends of B, and a new version of B appears, B will not be updated.

This must be wrong since my procedure does sometimes offer to update
non-world packages

> As a result eix-test-obsolete finds that I have packages installed that
> are no longer in the database.
>
> I could do 
>
> emerge --update the-2-dozen-such-packages
>
> Is that wise?

I would still want to know if the executing the last emerge command is
wise and also would like to understand what  my update world procedure
is actually doing.

> thanks,
> allan

PS  Sorry for the error.  New rule no email to gentoo-user before my
morning shower.

Re: [gentoo-user] Re: updating ALL packages

[Michael Orlitzky]

On 07/23/2014 09:59 AM, gottlieb@nyu.edu wrote:
> 
> This must be wrong since my procedure does sometimes offer to update
> non-world packages

...

> I would still want to know if the executing the last emerge command is
> wise and also would like to understand what  my update world procedure
> is actually doing.

I think all you're missing is the build-time dependencies. If one
package needs another (say, cmake) to build but not to run, then portage
won't update it by default when you update @world. You can change that
behavior by passing --with-bdeps to emerge.

From `man emerge`:

  --with-bdeps < y | n >
    In dependency calculations, pull in build time dependencies that
    are not strictly required. This defaults to ´n´ for installation
    actions, meaning they will not be installed,  and  ´y´  for  the
    --depclean  action, meaning they will not be removed.  This set‐
    ting can be added to EMERGE_DEFAULT_OPTS (see make.conf(5))  and
    later overridden via the command line.

Re: [gentoo-user] updating ALL packages

[Neil Bothwick]

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

On Wed, 23 Jul 2014 09:24:44 -0400, gottlieb@nyu.edu wrote:

> I had mistakenly thought this would update all packages not at the
> latest version (subject to package.accept_keywords, package.mask, ...).

It only updates runtime dependencies, you need --with-bdeps=y to update
all dependencies. However, the default is no for a good reason, there's
no need to update build time deps once the package is installed.
 
> I now realize that it only does this for the packages in world and then
> follows the dependency tree.  So if package A in world is up to date, A
> depends of B, and a new version of B appears, B will not be updated.
> 
> As a result eix-test-obsolete finds that I have packages installed that
> are no longer in the database.

That shouldn't happen. If an installed package is removed for the tree,
portage should either install the highest version that matches your
settings or print a warning.

> I could do 
> 
> emerge --update the-2-dozen-such-packages
> 
> Is that wise?

No, as it will add them to world (this behaviour of -u appears to vary
depending on portage version, wind direction and sunspot activity). Use
--oneshot.


-- 
Neil Bothwick

You can't teach a new mouse old clicks.

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

Re: [gentoo-user] updating ALL packages

[gottlieb]

On Thu, Jul 24 2014, Neil Bothwick wrote:

> On Wed, 23 Jul 2014 09:24:44 -0400, gottlieb@nyu.edu wrote:
>
>> I had mistakenly thought this would update all packages not at the
>> latest version (subject to package.accept_keywords, package.mask, ...).
>
> It only updates runtime dependencies, you need --with-bdeps=y to update
> all dependencies.

Thank you and michael for this point.

> However, the default is no for a good reason, there's no need to
> update build time deps once the package is installed.

I see.

>> I now realize that it only does this for the packages in world and then
>> follows the dependency tree.  So if package A in world is up to date, A
>> depends of B, and a new version of B appears, B will not be updated.
>> 
>> As a result eix-test-obsolete finds that I have packages installed that
>> are no longer in the database.
>
> That shouldn't happen. If an installed package is removed for the tree,
> portage should either install the highest version that matches your
> settings or print a warning.

I am not sure if you consider the message from eix-test-obsolete
as the message from portage.

eix-test-obsolete prints (among other things)

Installed packages with a version not in the database (or masked):
[lines omitted]
[U] virtual/perl-CPAN-Meta-Requirements (2.125.0@10/29/2013 -> (~)2.125.0-r1): Virtual for CPAN-Meta-Requirements

eix virtual/perl-CPAN-Meta-Requirements   prints

[U] virtual/perl-CPAN-Meta-Requirements
     Available versions:  2.122.0-r2 (~)2.125.0-r1
     Installed versions:  2.125.0(09:25:35 PM 10/29/2013)

/etc/portage/package.accept_keywords/goingstable contains
~virtual/perl-CPAN-Meta-Requirements-2.125.0

I thought this would be updated to  2.125.0-r1 but
my update world (withOUT bdeps=y) says nothing to merge
and prints no error or warning

>> I could do 
>> 
>> emerge --update the-2-dozen-such-packages
>> 
>> Is that wise?
>
> No, as it will add them to world (this behaviour of -u appears to vary
> depending on portage version, wind direction and sunspot activity). Use
> --oneshot.

Understood.  And I remember the discussion on the list about the meaning
of -u.

emerge -u -1 virtual/perl-CPAN-Meta-Requirements
reveals what is probably my real problem

[ebuild     U ~] virtual/perl-CPAN-Meta-Requirements-2.125.0-r1 [2.125.0] 0 kB
[nomerge       ]  perl-core/CPAN-Meta-Requirements-2.125.0 
[ebuild     UD ]   virtual/perl-version-0.990.100 [0.990.400] 0 kB
[ebuild     UD ]    perl-core/version-0.990.100 [0.990.400] 105 kB

upgrading virtual/perl-CPAN-Meta-Requirements entails downgrading two
other perl packages (or bumping their version in goingstable, which I
remember you suggest).

I am going away for 2 weeks, but when I return I will look carefully at
the (mostly perl) files that eix-test-obsolete complains about.  I am
hopeful that armed with emerge -u -1 and/or --with-bdeps=y I can remove
the warnings from eix-test-obsolete.

Once again, thank you both,
allan

Re: [gentoo-user] updating ALL packages

[Alan McKinnon]

On 25/07/2014 03:51, gottlieb@nyu.edu wrote:
> On Thu, Jul 24 2014, Neil Bothwick wrote:
> 
>> On Wed, 23 Jul 2014 09:24:44 -0400, gottlieb@nyu.edu wrote:
>>
>>> I had mistakenly thought this would update all packages not at the
>>> latest version (subject to package.accept_keywords, package.mask, ...).
>>
>> It only updates runtime dependencies, you need --with-bdeps=y to update
>> all dependencies.
> 
> Thank you and michael for this point.
> 
>> However, the default is no for a good reason, there's no need to
>> update build time deps once the package is installed.
> 
> I see.
> 
>>> I now realize that it only does this for the packages in world and then
>>> follows the dependency tree.  So if package A in world is up to date, A
>>> depends of B, and a new version of B appears, B will not be updated.
>>>
>>> As a result eix-test-obsolete finds that I have packages installed that
>>> are no longer in the database.
>>
>> That shouldn't happen. If an installed package is removed for the tree,
>> portage should either install the highest version that matches your
>> settings or print a warning.
> 
> I am not sure if you consider the message from eix-test-obsolete
> as the message from portage.
> 
> eix-test-obsolete prints (among other things)
> 
> Installed packages with a version not in the database (or masked):
> [lines omitted]
> [U] virtual/perl-CPAN-Meta-Requirements (2.125.0@10/29/2013 -> (~)2.125.0-r1): Virtual for CPAN-Meta-Requirements
> 
> eix virtual/perl-CPAN-Meta-Requirements   prints
> 
> [U] virtual/perl-CPAN-Meta-Requirements
>      Available versions:  2.122.0-r2 (~)2.125.0-r1
>      Installed versions:  2.125.0(09:25:35 PM 10/29/2013)
> 
> /etc/portage/package.accept_keywords/goingstable contains
> ~virtual/perl-CPAN-Meta-Requirements-2.125.0
> 
> I thought this would be updated to  2.125.0-r1 but
> my update world (withOUT bdeps=y) says nothing to merge
> and prints no error or warning

That is correct. The package is needed to build stuff and nothing in the
current list of packages to be built needs the package to do it.
Should you sometime update a package that does depend on perl-CPAN-Meta
to be built, then perl-CPAN-Meta will then be updated



>>> I could do 
>>>
>>> emerge --update the-2-dozen-such-packages
>>>
>>> Is that wise?
>>
>> No, as it will add them to world (this behaviour of -u appears to vary
>> depending on portage version, wind direction and sunspot activity). Use
>> --oneshot.
> 
> Understood.  And I remember the discussion on the list about the meaning
> of -u.
> 
> emerge -u -1 virtual/perl-CPAN-Meta-Requirements
> reveals what is probably my real problem
> 
> [ebuild     U ~] virtual/perl-CPAN-Meta-Requirements-2.125.0-r1 [2.125.0] 0 kB
> [nomerge       ]  perl-core/CPAN-Meta-Requirements-2.125.0 
> [ebuild     UD ]   virtual/perl-version-0.990.100 [0.990.400] 0 kB
> [ebuild     UD ]    perl-core/version-0.990.100 [0.990.400] 105 kB
> 
> upgrading virtual/perl-CPAN-Meta-Requirements entails downgrading two
> other perl packages (or bumping their version in goingstable, which I
> remember you suggest).
> 
> I am going away for 2 weeks, but when I return I will look carefully at
> the (mostly perl) files that eix-test-obsolete complains about.  I am
> hopeful that armed with emerge -u -1 and/or --with-bdeps=y I can remove
> the warnings from eix-test-obsolete.

Just do one world update with bdeps=y

Portage will then update the packages that it has been skipping



> 
> Once again, thank you both,
> allan
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] updating ALL packages

[gottlieb]

On Fri, Jul 25 2014, Alan McKinnon wrote:

> On 25/07/2014 03:51, gottlieb@nyu.edu wrote:
>> On Thu, Jul 24 2014, Neil Bothwick wrote:
>> 
>>> On Wed, 23 Jul 2014 09:24:44 -0400, gottlieb@nyu.edu wrote:
>>>
>>>> I had mistakenly thought this would update all packages not at the
>>>> latest version (subject to package.accept_keywords, package.mask, ...).
>>>
>>> It only updates runtime dependencies, you need --with-bdeps=y to update
>>> all dependencies.
>> 
>> Thank you and michael for this point.
>> 
>>> However, the default is no for a good reason, there's no need to
>>> update build time deps once the package is installed.
>> 
>> I see.
>> 
>>>> I now realize that it only does this for the packages in world and then
>>>> follows the dependency tree.  So if package A in world is up to date, A
>>>> depends of B, and a new version of B appears, B will not be updated.
>>>>
>>>> As a result eix-test-obsolete finds that I have packages installed that
>>>> are no longer in the database.
>>>
>>> That shouldn't happen. If an installed package is removed for the tree,
>>> portage should either install the highest version that matches your
>>> settings or print a warning.
>> 
>> I am not sure if you consider the message from eix-test-obsolete
>> as the message from portage.
>> 
>> eix-test-obsolete prints (among other things)
>> 
>> Installed packages with a version not in the database (or masked):
>> [lines omitted]
>> [U] virtual/perl-CPAN-Meta-Requirements (2.125.0@10/29/2013 ->
>> (~)2.125.0-r1): Virtual for CPAN-Meta-Requirements
>> 
>> eix virtual/perl-CPAN-Meta-Requirements   prints
>> 
>> [U] virtual/perl-CPAN-Meta-Requirements
>>      Available versions:  2.122.0-r2 (~)2.125.0-r1
>>      Installed versions:  2.125.0(09:25:35 PM 10/29/2013)
>> 
>> /etc/portage/package.accept_keywords/goingstable contains
>> ~virtual/perl-CPAN-Meta-Requirements-2.125.0
>> 
>> I thought this would be updated to  2.125.0-r1 but
>> my update world (withOUT bdeps=y) says nothing to merge
>> and prints no error or warning
>
> That is correct. The package is needed to build stuff and nothing in the
> current list of packages to be built needs the package to do it.
> Should you sometime update a package that does depend on perl-CPAN-Meta
> to be built, then perl-CPAN-Meta will then be updated
>
>
>
>>>> I could do 
>>>>
>>>> emerge --update the-2-dozen-such-packages
>>>>
>>>> Is that wise?
>>>
>>> No, as it will add them to world (this behaviour of -u appears to vary
>>> depending on portage version, wind direction and sunspot activity). Use
>>> --oneshot.
>> 
>> Understood.  And I remember the discussion on the list about the meaning
>> of -u.
>> 
>> emerge -u -1 virtual/perl-CPAN-Meta-Requirements
>> reveals what is probably my real problem
>> 
>> [ebuild     U ~] virtual/perl-CPAN-Meta-Requirements-2.125.0-r1 [2.125.0] 0 kB
>> [nomerge       ]  perl-core/CPAN-Meta-Requirements-2.125.0 
>> [ebuild     UD ]   virtual/perl-version-0.990.100 [0.990.400] 0 kB
>> [ebuild     UD ]    perl-core/version-0.990.100 [0.990.400] 105 kB
>> 
>> upgrading virtual/perl-CPAN-Meta-Requirements entails downgrading two
>> other perl packages (or bumping their version in goingstable, which I
>> remember you suggest).
>> 
>> I am going away for 2 weeks, but when I return I will look carefully at
>> the (mostly perl) files that eix-test-obsolete complains about.  I am
>> hopeful that armed with emerge -u -1 and/or --with-bdeps=y I can remove
>> the warnings from eix-test-obsolete.
>
> Just do one world update with bdeps=y
>
> Portage will then update the packages that it has been skipping
>
Not quite that simple due to the bothwick
package.accept_keywords/goingstable.  I did a --pretend run and saw
several proposed downgrades (to packages required by the ones mentioned
in eix-test-obsolete).  Neil recommends that in these cases I update
goingstable to permit upgrades instead.

thanks for your interest and help
allan

Re: [gentoo-user] updating ALL packages

[Alan McKinnon]

On 23/07/2014 15:24, gottlieb@nyu.edu wrote:
> My normal updating procedure is
> 
> EMERGE_DEFAULT_OPTS="--ask --deep --tree --verbose --jobs --load-average=5"
> emerge --update --changed-use --keep-going  @world
> 
> I had mistakenly thought this would update all packages not at the
> latest version (subject to package.accept_keywords, package.mask, ...).
> 
> I now realize that it only does this for the packages in world and then
> follows the dependency tree.  So if package A in world is up to date, A
> depends of B, and a new version of B appears, B will not be updated.
> 
> As a result eix-test-obsolete finds that I have packages installed that
> are no longer in the database.
> 
> I could do 
> 
> emerge --update the-2-dozen-such-packages

emerge --depclean


> 
> Is that wise?
> 
> thanks,
> allan
> 
> PS This system is in the midst of the multi-month bothwick "goingstable"
> procedure.  I don't know if that is relevant to the decision.
> 
> Neil Bothwick wrote:
>>
>> You can generate the list with
>>
>> qlist -ICv | sed -e 's/^/~/' -e 's/-r[1-9]$//' \
>>     >/etc/portage/package.accept_keywords/goingstable
>>
>> This allows revision updates, which is useful as they usually contain bug
>> or security fixes, but doesn't allow any higher versions.
>>
>> Occasionally running eix-test-obsolete will let you know which entries
>> have become redundant because stable has caught up with them.
>>
>> I recently used it to move a machine from testing to stable. The one
>> caveat is that sometimes the testing version your have installed, and in
>> package.accept_keywords, is removed from the tree so portage wants to
>> downgrade to the latest stable version. You have the choice of letting
>> this happen or unmasking a later testing version.
> 
> [ subsequently he recommended using the latter choice ]
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] updating ALL packages

[gottlieb]

On Fri, Jul 25 2014, Alan McKinnon wrote:

> On 23/07/2014 15:24, gottlieb@nyu.edu wrote:
>> My normal updating procedure is
>> 
>> EMERGE_DEFAULT_OPTS="--ask --deep --tree --verbose --jobs --load-average=5"
>> emerge --update --changed-use --keep-going  @world
>> 
>> I had mistakenly thought this would update all packages not at the
>> latest version (subject to package.accept_keywords, package.mask, ...).
>> 
>> I now realize that it only does this for the packages in world and then
>> follows the dependency tree.  So if package A in world is up to date, A
>> depends of B, and a new version of B appears, B will not be updated.
>> 
>> As a result eix-test-obsolete finds that I have packages installed that
>> are no longer in the database.
>> 
>> I could do 
>> 
>> emerge --update the-2-dozen-such-packages
>
> emerge --depclean

I had done that and nothing turned up.
allan