James wrote:
>[cr
> DAG's
All this can work only if you reflect the complete history
in the DAG. Such approaches had been discussed and eliminated
as unrealistic: You do not want to keep the history forever;
the data will always grow and eventually be too much.
Moreover, there can be overlays whi
Mike Gilbert gentoo.org> writes:
> Basically, yes. If [R]DEPEND in /var/db/pkg is different from the
> values in the ebuilds in the tree, changed-deps will select it.
> > Also, these two similar commands return different results (I have
> > bdeps=y in DEFAULT_OPTS btw):
> >
> > emerge -uND --
Martin Vaeth mvath.de> writes:
>
> James tampabay.rr.com> wrote:
> >
> > Basically from my point of view, something like TUP [1] is needed so
> > that at dependency check time you only list files that need
> > attention (linking, loading, compiling etc) thus speeding up the
> > update processes
On Mon, Sep 28, 2015 at 3:57 AM, Martin Vaeth wrote:
> Rich Freeman wrote:
>>
>> Sure, but the portage team can really only dictate the upstream
>> defaults of portage, not tree policy.
>
> As I understand, they intend to remove non-dynamic deps
> (if they agreed to not implement it properly for
Rich Freeman wrote:
>
> Sure, but the portage team can really only dictate the upstream
> defaults of portage, not tree policy.
As I understand, they intend to remove non-dynamic deps
(if they agreed to not implement it properly for sub-slots,
this makes sense).
So we are not speaking about defa
On Sun, Sep 27, 2015 at 8:33 PM, Martin Vaeth wrote:
> Rich Freeman wrote:
>> There really wasn't much loud objection when the proposal came up
>> again last week
>
> This does not mean that everybody agreed.
> However, all arguments had been exchanged before,
> so repeating them would just have
James wrote:
>
> Basically from my point of view, something like TUP [1] is needed so
> that at dependency check time you only list files that need
> attention (linking, loading, compiling etc) thus speeding up the
> update processes for the Package Manager (portage).
This is a misunderstanding (
Rich Freeman wrote:
> There really wasn't much loud objection when the proposal came up
> again last week
This does not mean that everybody agreed.
However, all arguments had been exchanged before,
so repeating them would just have been pointless:
Eventually a decision had to be made, and I am co
Michael Orlitzky wrote:
>
> With dynamic deps, portage will scan (that is, execute) all of the
> ebuilds for installed packages that could affect the dependency graph.
This is not correct. This data is already stored in metadata/
(or in /var/cache/edb, depending on the backend),
and just has to b
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 a
Michael Orlitzky gentoo.org> writes:
> With dynamic deps, portage will scan (that is, execute) all of the
> ebuilds for installed packages that could affect the dependency graph.
> If any of those ebuilds have changed, portage will use the new
> information rather than the info present when you
11 matches
Mail list logo