[gentoo-user] portage inconsistency?

[gentoo-user] portage inconsistency?

[maxim wexler]

Hi group,

At tail of emerge --sync its says now emerge portage.

So, emerge portage results in one package being
installed, portage, 61kb.

emerge -u portage lines up 5 or 6 packages plus
portage, 18Mb.

Went ahead and just did the one package, figuring
later I could do an emerge -u for the rest of it.

But this is what happens:

heathen@localhost ~ $ emerge -pv portage

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

Calculating dependencies... done!
[ebuild   R   ] sys-apps/portage-2.1.2.9  USE="-build
-doc -epydoc (-selinux)" LINGUAS="-pl" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0
kB

What I expected.

heathen@localhost ~ $ emerge -puv portage

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

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 kB

So why doesn't it list the upgrade part now?

Maxim


       
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] portage inconsistency?

[Александър Л. Димитров]

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

Hello Maxim

On 15:46 Mon 16 Jul, maxim wexler wrote:
> At tail of emerge --sync its says now emerge portage.

Yes, it does that every time there is a new portage version available.
 
> emerge -u portage lines up 5 or 6 packages plus
> portage, 18Mb.
 
from the emerge manpage:

"--update (-u)
      Updates  packages  to  the  best version available, which may not always be the
      highest version number due to masking for testing and development.   This  will
      also  update direct dependencies which may not be what you want.  Package atoms
      specified on the command line are greedy, meaning  that  unspecific  atoms  may
      match multiple installed versions of slotted packages."

> So why doesn't it list the upgrade part now?

If you look carefully at the first line 'emerge -pv portage' gives you,
you will notice that it says `[ebuild   R   ] sys-apps/portage'. The `R'
is for `Rebuild' - as your portage is already at the latest version
emerge wants to rebuild it. If you use the -u flag it just searches for
updates, finds none and hence does not suggest any installation.

I suggest you should read throgh emerge(1) and portage(5) mapages and
also read the online docs in the handbook to get familiar with the
portage system.


Regards,
	Aleks

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

Re: [gentoo-user] portage inconsistency?

[Iván Pérez Domínguez]

maxim wexler wrote:
> Hi group,
> 
> At tail of emerge --sync its says now emerge portage.
> 
> So, emerge portage results in one package being
> installed, portage, 61kb.
> 
> emerge -u portage lines up 5 or 6 packages plus
> portage, 18Mb.

Can you tell us the list of packages it reported?
(downgrade and run emerge -u again).

> Went ahead and just did the one package, figuring
> later I could do an emerge -u for the rest of it.
> 
> But this is what happens:
> 
> heathen@localhost ~ $ emerge -pv portage
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R   ] sys-apps/portage-2.1.2.9  USE="-build
> -doc -epydoc (-selinux)" LINGUAS="-pl" 0 kB
> 
> Total: 1 package (1 reinstall), Size of downloads: 0
> kB
> 
> What I expected.
> 
> heathen@localhost ~ $ emerge -puv portage
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!

That happened to me too with a different package and I thought the same
you did.

>From the man page:
"Updates  packages to the best version available, which may not always
be the highest version number due to masking for testing and
development.  This will also update direct dependencies  which
may not be what you want. Package atoms specified on the command line
are greedy, meaning that unspecific atoms may match multiple installed
versions of slotted packages."

> Total: 0 packages, Size of downloads: 0 kB
> 
> So why doesn't it list the upgrade part now?
> 
> Maxim

Ivan Perez.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] portage inconsistency?

[maxim wexler]

> 
> Can you tell us the list of packages it reported?
> (downgrade and run emerge -u again).

No, I didn't scroll and paste the output :(

How do I "downgrade"? emerge -pC gives me an ugly
warning.

Can't see it man or --help.

Maxim


       
____________________________________________________________________________________
Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] portage inconsistency?

[Bo Ørsted Andresen]

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

On Tuesday 17 July 2007 00:46:08 maxim wexler wrote:
> So, emerge portage results in one package being
> installed, portage, 61kb.
>
> emerge -u portage lines up 5 or 6 packages plus
> portage, 18Mb.
>
> Went ahead and just did the one package, figuring
> later I could do an emerge -u for the rest of it.
>
> But this is what happens:
>
> heathen@localhost ~ $ emerge -pv portage
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild   R   ] sys-apps/portage-2.1.2.9  USE="-build
> -doc -epydoc (-selinux)" LINGUAS="-pl" 0 kB
>
> Total: 1 package (1 reinstall), Size of downloads: 0
> kB
>
> What I expected.
>
> heathen@localhost ~ $ emerge -puv portage
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
>
> Total: 0 packages, Size of downloads: 0 kB
>
> So why doesn't it list the upgrade part now?

Because --update stops calculating deps when none of the specified targets 
need updating. Only --deep checks the consistency of all dependencies even 
when none of the targets need updating. You could argue it's a deficiency in 
portage (although well-known)..

-- 
Bo Andresen

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

Re: [gentoo-user] portage inconsistency?

[Tim Allingham]

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

On Sun, 2007-08-05 at 16:32 +0200, Bo Ørsted Andresen wrote:
> On Tuesday 17 July 2007 00:46:08 maxim wexler wrote:
> > So, emerge portage results in one package being
> > installed, portage, 61kb.
> >
> > emerge -u portage lines up 5 or 6 packages plus
> > portage, 18Mb.
> >
> > Went ahead and just did the one package, figuring
> > later I could do an emerge -u for the rest of it.
> >
> > But this is what happens:
> >
> > heathen@localhost ~ $ emerge -pv portage
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> > [ebuild   R   ] sys-apps/portage-2.1.2.9  USE="-build
> > -doc -epydoc (-selinux)" LINGUAS="-pl" 0 kB
> >
> > Total: 1 package (1 reinstall), Size of downloads: 0
> > kB
> >
> > What I expected.
> >
> > heathen@localhost ~ $ emerge -puv portage
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> >
> > Total: 0 packages, Size of downloads: 0 kB
> >
> > So why doesn't it list the upgrade part now?
> 
> Because --update stops calculating deps when none of the specified targets 
> need updating. Only --deep checks the consistency of all dependencies even 
> when none of the targets need updating. You could argue it's a deficiency in 
> portage (although well-known)..
> 

meaning that an emerge -pvuD world/portage should show the upgrades

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

Re: [gentoo-user] portage inconsistency?

[Mark Shields]

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

On 8/5/07, Tim Allingham <deserted@westnet.com.au> wrote:
>
> On Sun, 2007-08-05 at 16:32 +0200, Bo Ørsted Andresen wrote:
> > On Tuesday 17 July 2007 00:46:08 maxim wexler wrote:
> > > So, emerge portage results in one package being
> > > installed, portage, 61kb.
> > >
> > > emerge -u portage lines up 5 or 6 packages plus
> > > portage, 18Mb.
> > >
> > > Went ahead and just did the one package, figuring
> > > later I could do an emerge -u for the rest of it.
> > >
> > > But this is what happens:
> > >
> > > heathen@localhost ~ $ emerge -pv portage
> > >
> > > These are the packages that would be merged, in order:
> > >
> > > Calculating dependencies... done!
> > > [ebuild   R   ] sys-apps/portage-2.1.2.9  USE="-build
> > > -doc -epydoc (-selinux)" LINGUAS="-pl" 0 kB
> > >
> > > Total: 1 package (1 reinstall), Size of downloads: 0
> > > kB
> > >
> > > What I expected.
> > >
> > > heathen@localhost ~ $ emerge -puv portage
> > >
> > > These are the packages that would be merged, in order:
> > >
> > > Calculating dependencies... done!
> > >
> > > Total: 0 packages, Size of downloads: 0 kB
> > >
> > > So why doesn't it list the upgrade part now?
> >
> > Because --update stops calculating deps when none of the specified
> targets
> > need updating. Only --deep checks the consistency of all dependencies
> even
> > when none of the targets need updating. You could argue it's a
> deficiency in
> > portage (although well-known)..
> >
>
> meaning that an emerge -pvuD world/portage should show the upgrades
>
>
I just use emerge -DNavu world (can always substitute -p in there for emerge
-DNpvu world) - helps to make sure all packages are up to date, including
use flags for those packages.

-- 
- Mark Shields

[-- Attachment #2: Type: text/html, Size: 2381 bytes --]

Re: [gentoo-user] portage inconsistency?

[Bo Ørsted Andresen]

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

On Sunday 05 August 2007 17:13:46 Tim Allingham wrote:
> > Because --update stops calculating deps when none of the specified
> > targets need updating. Only --deep checks the consistency of all
> > dependencies even when none of the targets need updating. You could argue
> > it's a deficiency in portage (although well-known)..
>
> meaning that an emerge -pvuD world/portage should show the upgrades

Exactly. But it may show a lot more than that.. :p

-- 
Bo Andresen

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

Re: [gentoo-user] portage inconsistency?

[Abraham Marín Pérez]

Bo Ørsted Andresen escribió:
> On Tuesday 17 July 2007 00:46:08 maxim wexler wrote:
>   
>> So, emerge portage results in one package being
>> installed, portage, 61kb.
>>
>> emerge -u portage lines up 5 or 6 packages plus
>> portage, 18Mb.
>>
>> Went ahead and just did the one package, figuring
>> later I could do an emerge -u for the rest of it.
>>
>> But this is what happens:
>>
>> heathen@localhost ~ $ emerge -pv portage
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>> [ebuild   R   ] sys-apps/portage-2.1.2.9  USE="-build
>> -doc -epydoc (-selinux)" LINGUAS="-pl" 0 kB
>>
>> Total: 1 package (1 reinstall), Size of downloads: 0
>> kB
>>
>> What I expected.
>>
>> heathen@localhost ~ $ emerge -puv portage
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>>
>> Total: 0 packages, Size of downloads: 0 kB
>>
>> So why doesn't it list the upgrade part now?
>>     
>
> Because --update stops calculating deps when none of the specified targets 
> need updating. Only --deep checks the consistency of all dependencies even 
> when none of the targets need updating. You could argue it's a deficiency in 
> portage (although well-known)..
>
>   

It may sound a bit off-topic, but there is (at least) one very good 
reason for portage behaving this way, just think of the following scenario:

We have installed an application called APP (yes, very smart name) and 
this application depends on a dynamic library called LIB (yet smarter 
name). At installation APP was in version 1.0 and LIB in version 2.0.

Now think there's a new version available of LIB, let's say version 2.1, 
but the latest version of APP is still 1.0. If portage performed a deep 
update by default LIB would be rebuilt, but no APP, what would cause 
broken dependencies on APP (remember LIB is a dynamic library). However, 
is you don't update LIB unless you update also APP you will prevent this 
problem*.

Just my 0.02 ;-)

Abraham


* Needless to say, the problem will still arise if two applications 
depend on the same dynamic library, which is a common case, and only one 
of them is updated, but still it's an improvement.

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: portage inconsistency?

[Remy Blank]

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

Abraham Marín Pérez wrote:
> Now think there's a new version available of LIB, let's say version 2.1, 
> but the latest version of APP is still 1.0. If portage performed a deep 
> update by default LIB would be rebuilt, but no APP, what would cause 
> broken dependencies on APP (remember LIB is a dynamic library). However, 
> is you don't update LIB unless you update also APP you will prevent this 
> problem*.

That's what revdep-rebuild is for. Update your LIB, run revdep-rebuild,
and if APP is really broken by the LIB update (it doesn't have to be),
it will be rebuilt.

-- Remy


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [gentoo-user] portage inconsistency?

[Neil Bothwick]

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

On Mon, 06 Aug 2007 10:45:25 +0200, Abraham Marín Pérez wrote:

> Now think there's a new version available of LIB, let's say version
> 2.1, but the latest version of APP is still 1.0. If portage performed a
> deep update by default LIB would be rebuilt, but no APP, what would
> cause broken dependencies on APP (remember LIB is a dynamic library).
> However, is you don't update LIB unless you update also APP you will
> prevent this problem*.

SLOTs deal with this problem, allowing you to have LIB-1.0 and LIB-2.0
installed simultaneously.

> * Needless to say, the problem will still arise if two applications 
> depend on the same dynamic library, which is a common case, and only
> one of them is updated, but still it's an improvement.

Unless you use SLOTs.


-- 
Neil Bothwick

A. Top posters.
Q. What is the most annoying thing on Usenet?

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

Re: [gentoo-user] Re: portage inconsistency?

[Abraham Marín Pérez]

Remy Blank escribió:
> Abraham Marín Pérez wrote:
>   
>> Now think there's a new version available of LIB, let's say version 2.1, 
>> but the latest version of APP is still 1.0. If portage performed a deep 
>> update by default LIB would be rebuilt, but no APP, what would cause 
>> broken dependencies on APP (remember LIB is a dynamic library). However, 
>> is you don't update LIB unless you update also APP you will prevent this 
>> problem*.
>>     
>
> That's what revdep-rebuild is for. Update your LIB, run revdep-rebuild,
> and if APP is really broken by the LIB update (it doesn't have to be),
> it will be rebuilt.
>
> -- Remy
>
>   
That is indeed true, however, it will always be better keeping things 
right than breaking and fixing as a rule, don't you think?

Abraham

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] portage inconsistency?

[Abraham Marín Pérez]

Neil Bothwick escribió:
> On Mon, 06 Aug 2007 10:45:25 +0200, Abraham Marín Pérez wrote:
>
>   
>> Now think there's a new version available of LIB, let's say version
>> 2.1, but the latest version of APP is still 1.0. If portage performed a
>> deep update by default LIB would be rebuilt, but no APP, what would
>> cause broken dependencies on APP (remember LIB is a dynamic library).
>> However, is you don't update LIB unless you update also APP you will
>> prevent this problem*.
>>     
>
> SLOTs deal with this problem, allowing you to have LIB-1.0 and LIB-2.0
> installed simultaneously.
>   

I'm afraid you misunderstood what I said. As you said, slots let 
different versions of the same package being installed in your system, 
however, that's only done when you REALLY need to do so; one of the 
cases in which you would have such a necessity is the one of a library 
which changes its API through versions in a way that breaks backwards 
compatibility. In this case you may have apps using the old API and apps 
using the new one, and hence you would need both versions installed.

However, if you can go with only one version slots aren't used, can you 
imagine the great amount of garbage installed in your box if you had to 
use a new slot for every new version of a package? That's just crazy.

In conclusion, if you update a library and uninstall its previous 
version (which you'd do very often, even if you haven't noticed it 
before) you may need to rebuild the apps using that library as well, 
there's no way you escape from that.

Abraham

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: portage inconsistency?

[Remy Blank]

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

Abraham Marín Pérez wrote:
> That is indeed true, however, it will always be better keeping things 
> right than breaking and fixing as a rule, don't you think?

The thing is, you will *have to* break things at some point anyway. In
your case, it will be when you decide to update LIB (because you want to
have the new features, or because another package needs the new
version). Between the LIB update and the APP recompilation, APP will be
broken.

Even worse, if you don't know that the LIB update will break APP, you
might not notice immediately that APP is broken, or you might only get
some strange results from APP. That's where revdep-rebuild steps in: it
can tell you that APP is broken, and what's needed to fix it. So you're
better off running it consistently after your regular updates.

-- Remy


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [gentoo-user] Re: portage inconsistency?

[Abraham Marín Pérez]

Remy Blank escribió:
> Abraham Marín Pérez wrote:
>   
>> That is indeed true, however, it will always be better keeping things 
>> right than breaking and fixing as a rule, don't you think?
>>     
>
> The thing is, you will *have to* break things at some point anyway. In
> your case, it will be when you decide to update LIB (because you want to
> have the new features, or because another package needs the new
> version). Between the LIB update and the APP recompilation, APP will be
> broken.
>
> Even worse, if you don't know that the LIB update will break APP, you
> might not notice immediately that APP is broken, or you might only get
> some strange results from APP. That's where revdep-rebuild steps in: it
> can tell you that APP is broken, and what's needed to fix it. So you're
> better off running it consistently after your regular updates.
>
>   

I'm not talking about not needing revdep-rebuild nor saying non-deep 
updates would prevent breaking dependencies, I just said that non-deep 
updates will *reduce* the amount of packages that need to be rebuilt. I 
systematically run revdep-rebuild after every update world (in fact, 
it's all in a script which performs update world, revdep-rebuild and 
update-eix), but I'd rather have it reinstalling 2 packages than 20. 
That's all.

Abraham

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: portage inconsistency?

[Neil Bothwick]

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

On Mon, 06 Aug 2007 12:40:38 +0200, Remy Blank wrote:

> Even worse, if you don't know that the LIB update will break APP, you
> might not notice immediately that APP is broken, or you might only get
> some strange results from APP. That's where revdep-rebuild steps in: it
> can tell you that APP is broken, and what's needed to fix it. So you're
> better off running it consistently after your regular updates.

If the update is likely to cause such breakage, the ebuild should warn of
this, as many do, giving the exact command to run to fix such breakage
before it becomes a problem.

Such breakages are inevitable on a source based system using dynamic
libraries. Fortunately, being a source based system makes the fix simple.
Try dealing with the same problems on a binary distro.


-- 
Neil Bothwick

If at first you don't succeed, call it Windows NT.

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