public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Orlitzky <mjo@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: dynamic deps, wtf are they exactly
Date: Sun, 27 Sep 2015 18:41:00 -0400	[thread overview]
Message-ID: <5608707C.8050009@gentoo.org> (raw)
In-Reply-To: <loom.20150927T211152-701@post.gmane.org>

On 09/27/2015 03:52 PM, James wrote:
> 
>> That's nice, because now if you want to install or update something
>> else, portage doesn't have to re-execute every ebuild/eclass that could
>> possibly affect the new thing -- it only has to check the VDB.
> 
> I think that this is what GLEP-64 is all about. Enhancing the functional
> utilityh of the VDB with a DAG (Directed Acyclic Graph)?
> 

AFAIK, that GLEP is just about standardizing what goes in the VDB. The
VDB isn't specified in the PMS either, but all package managers need to
record e.g. what files were installed by the package. The GLEP would
standardize some of that stuff, and in the future, the PMS would give
you a way to read it reliably.

The dynamic dependencies issue is more about the contents of the VDB
being wrong.


>> I guess at some point there were a bunch of devs who were messing with
>> dependencies and not bothering to make revision bumps. This can cause
>> users pain, so portage added a new option to ignore the cache and rescan
>> every single relevant ebuild/eclass for sneaky dependency changes. This
>> ensures that portage has the correct dependencies in its head while it's
>> doing resolution, but is much slower.
> 
> There is no proper mechanism to accurately track all of these issue,
> currently, or did I miss this point?

The proper mechanism is "don't do that." The rules for when (not) to
revbump could go on for pages, if there was anyone qualified to write
them -- and I'm not convinced there is. The only safe thing to do is
always revbump unless you're damned sure that you're an exception.



  reply	other threads:[~2015-09-27 22:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-27 15:07 [gentoo-user] dynamic deps, wtf are they exactly Alan McKinnon
2015-09-27 15:12 ` Mike Gilbert
2015-09-27 15:28   ` Alan McKinnon
2015-09-27 16:12     ` Mike Gilbert
2015-09-29 12:26       ` [gentoo-user] " James
2015-09-27 17:26 ` [gentoo-user] " Michael Orlitzky
2015-09-27 19:34   ` Alan McKinnon
2015-09-27 22:21     ` Michael Orlitzky
2015-09-27 22:32       ` Alan McKinnon
2015-09-27 22:52       ` Rich Freeman
2015-09-28  0:33         ` [gentoo-user] " Martin Vaeth
2015-09-28  1:27           ` Rich Freeman
2015-09-28  7:57             ` Martin Vaeth
2015-09-28 10:55               ` Rich Freeman
2015-09-27 19:52   ` James
2015-09-27 22:41     ` Michael Orlitzky [this message]
2015-09-28  1:19     ` Martin Vaeth
2015-09-29 12:04       ` James
2015-09-30  9:41         ` Martin Vaeth
2015-09-28  0:32   ` Martin Vaeth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5608707C.8050009@gentoo.org \
    --to=mjo@gentoo.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox