Kent Fredric <kentfred...@gmail.com> wrote:
> 1. User installs Foo
> 2. Gentoo needs to change what Foo depends on
> 3. Gentoo simply tweaks the ebuild and doesn't bump [A]
> 4. User syncs.
> 5. Subsequent emerges see dependencies from [A] which are fixed and works
> in the interim
> 6. A gets removed.
> 7. User syncs.
> 8. Shadowing effect of [A] is removed, and Foo is now back
> depending on the wrong thing.
If you have 6., you have the same szenario even if Gentoo bumps [A],
if 4. is omitted (one must not rely on the user syncing very regularly).
Even much worse:
> I guess, in a way, pkgmove and dynamic deps are the same problem from
> different perspectives.
s/dynamic deps/changes in dependencies due to tree restructuring/
In a sense, it is. But even if you would use the space-consuming
variant of using some history:
If the restructuring of the tree happens *after* the package is removed
(that is, if 6. happens before the *cause* for 3.) you end up in any
case with a situation which can be broken in many aspects.
Orphant installs (without a corresponding ebuild) is a situation
which is impossible to handle "correctly".
The user must *strongly* be adviced ("forced" if gentoo would not
always leave choice) to remove the package unless he maintains the
corresponding ebuild in his own overlay.
Since there is no satisfactory solution for such orphant installs,
they should be kept out of the discussion.
> pkgmove is an instruction that "set( X ) that requires Y needs to change"
>
> and dynamic deps are "X requires set ( Y ) and needs to change."
s/dynamic deps/changes in dependencies due to tree restructuring/
The difference is that pkgmove can be done generically for all
packages while more complicated tree restructuring is impossible
to do generically. For instance, for a package split the maintainer
of the ebuild has to know which are the correct dependencies;
a package merge must usually be combined with appropriate USE-deps, etc.
