Re: [gentoo-user] Strangeness in dep calculation

[Roman Zilka]

> > Not quite. This is how I'm thinking: if '-ep world' says virtual/pam
> > needs to be installed, then it either
> > * is in the world file, or
> > * is in the system set, or
> > * is a buildtime or runtime dependency (immediate or deep) of one of
> > the packages in the world set (i.e., world file and system set
> > combined).
> >
> > But it's neither in my world file, nor in my system set (checked
> > with 'emerge -epO system'). So it must be a dependency. Then why
> > doesn't '-uDN --with-bdeps y world' demand it? Obviously,
> > virtual/pam is listed as necessary for running or building
> > something in my world set. '-uDN world' shouldn't omit merging
> > something I need to run my packages. And with '--with-bdeps y' it
> > also shouldn't omit merging something I might ever need to build
> > these packages.
> >
> > The quoted equery call shows that virtual/pam is needed to run 7
> > pieces of software in my world. (I understand it's not literally
> > needed for them to run, but that's the semantics of runtime deps
> > and portage has no way to know the difference, I suppose.) And it's
> > not an alternative to another possible dependency - it must be
> > virtual/pam (checked some of the ebuilds).
>
> I think this is the root cause of your questions. You say "portage has
> no way to know the difference" - who says that is true? Did you assume
> it?

It sure is possible. I assumed what I did because the ebuild of a
virtual and a normal package reveal no differences relevant to this,
as it seems to me with my level of knowledge. Also, asking for a
virtual as a runtime dep is done in the same way as asking for any
other package. Furthermore, the manpage for emerge says nothing about
the virtuals being different w.r.t. --update or any other option.

> Why should virtual packages behave like regular packages? They are
> even in a different category to everything else.
>
> Treating virtuals just like regular packages doesn't make sense to me.
> Treating them as variables does make sense - they get expanded into
> lists of possibilities and when the graph is resolved, the existence
> of the virtual goes away. But that is speculation on my part.

Why do we have so many virtuals installed then? But yeah, who knows...

> I think if you get an authoritative answer to that question, then we
> can continue to examine the behaviour. Otherwise we are just guessing.


> > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >
> > It seems that you assume that my current skype is a stable version.
> > In fact, it isn't - see the quoted grep of the ebuilds. There is
> > not a single stable version of skype in portage now. They're all
> > ~arch.
> >
> > My ACCEPT_KEYWORDS="amd64". 'emerge skype' (I'll be omitting the
> > '--autounmask y', it's the default anyway) wants to upgrade from my
> > current 2.1.0.81 ~skype to 2.2.0.35-r1, which happens to be the
> > latest available ~skype. I assume that's the strategy: if there's
> > no stable version available, at least get the latest ~arch version.
> > That's fine. But why doesn't the same strategy apply for a '-uDN
> > world'?
> >
> > The manpage says nothing about this, as my eyes interepret it. There
> > might be some unintended hidden behavior of --autounmask or
> > --update or something else. If it's intended, I'd still like to
> > understand the reasoning - just to get what's going on.
>
> You'd have to ask Zac what he intended. I can easily see the code
> being written such that emerging a package and updating world use
> completely different code paths, simply because they must evaluate
> things differently with subtle differences.
>
> You'd really have to read the code to get proper answers to your
> questions. As we say in the eXtreme Programming world:
>
> The code IS the design.

Well, I'm not going into the code. Do you think it's meaningful to
either bring these two issues into attention of Zac directly, or file
official bugs? I've never done either and lack experience on determining
when is the right time.:)

Neither of the two issues cause any visible harm in the system as a
whole - it's not like I'm not sleeping because of them. I stumbled upon
them by mere chance. I'm just trying to reveal a possible bug or two.

-rz