Peter Stuge <pe...@stuge.se> wrote:
>
> This suggests another data model bug to me: that dependencies belong
> to the dependent packages, rather than to dependency providers.
Sometimes it is this way, sometimes the opposite.
It would not be natural to associate to a huge library like openssl
the packages which use it (or can make use of it if compiled with
certain ./configure options).
> What I mean is that in the above example, bar "knows" that bar has
> turned into bar-{base,gui}, but foo doesn't.
But this is not always so.
I could also have given the example that bar is replaced by
another library which perhaps is (mainly) API but not ABI compatible
but nevertheless provides the same command line tools.
(Perhaps openssl and some of the planned successors are such an
example?)
So the installations of bar and bar-successor must block each other,
but nevertheless package foo would need to be recompiled if you want
to use the modern (presumably "safer") bar-successor - which cannot
be done for foo.
Again, in this situation the user relies on the outdated bar and
does not know it. Or - if something else needs bar-successor -
the user gets blockers.
> If the user updates their package database things would still work
> if 4 modifies the effective dependencies for foo to reflect the new
> reality of bar -> bar-{base,gui}.
I would be very careful with such magic modifications:
It is always dangerous if you rely on a heuristic which needs to
be "smarter" than the developer; no matter how many cases you
cover in the heuristic, sooner or later there will be some
split/replacement/alternative/merge of packages which cannot be treated
by the cases covered through the heuristics and which needs
some form of manual treatment in some cases.
> The more I think about dependencies the more convinced I am that
> dependency information must be versioned, ie. dependencies only
> matter in the context of the particular package database snapshot
> they came from, and that installed dependencies must be kept up to
> date as the package database evolves.
Yes, this is exactly the problem with static dependencies.
Regular revbumps *might* be a solution to this, but there is a
certain danger that due to certain (e.g. circular) static dependencies
blocking updates on certain user's systems the revbumps remain
"invisible" to these users.
This is probably not very likely, but I think I could construct
realistic such cases (with a "bug" in a dependency, such cases
are very easy to construct: Some =... instead of ~... is sufficient).
> Otherwise there's just a pile of heuristics, which throw people,
> which I guess is why dynamic-deps cause problems and ire.
This is exactly the main problem with dynamic dependencies.
To summarize a bit differently:
The issue is caused by gentoo being a rolling release distribution.
This causes permanent tree restructuring, and the latter is
incompatible with the idea that a package, once installed,
should remain working, unconditionally on the tree changes.
Users may expect and wish for the latter, but fact is that these
two requirements are in some situations incompatible with each other.
If you want a completely safe solution which in no special cases
can ever cause any problems, after every sync you would have to
unmerge every package and then remerge it again (resolving circular
deps by temporary removing of USE-flags and recompiling).
The other extreme are dynamic deps without any revbumps ever
which take only the rolling release character into account.
You have immediately the most current tree information,
but in some cases this contradicts the actual installed packages.
Now static-deps with many revbump and dynamic-deps with only a
revbumps for essential changes are two compromises between these
two extremes.
Nothing is safe *and* up-to-date in all cases, but both work
up to a reasonable number of exceptions:
The static-deps are on the "safe" solution side with more recompilations
but still possibly outdated information, the dynamic-deps are on the
rolling release side, requiring the user to take more responsibility
if he wants to avoid a broken system.
The highly emotional reactions on the topic are probably due to the
fact that corresponding users have systems which for some reason or
another should emphasize more the static or "rolling release" type
of gentoo: Shifting this emphasis is a politicial issue and
fundamental decision, of course.
