Hendrik Tews:
> Ximin Luo <[email protected]> writes:
>
>> Similar to the topkg-care situation, if they are going to keep it in
>> the same tarball as opam, this improves the Debian situation only
>> marginally since we'd have to do that source-duplication thing again.
>
> I agree that the source duplication is not nice. However, if
> upstream splits it in two packages that must always go in
> look-step, the effort for us will be almost the same, IMO.
>
Lock-step upgrades are only easy in the cases where the components, when viewed
as a single unit, do not form cyclic dependencies with other packages. Because
then, **you can treat these components as a single unit.** That's not the case
for topkg and it's not the case for opam. Lock step upgrades make things
*harder* in these latter cases. I gave two examples in my earlier reply to
Daniel. Here is a shorter but more abstract explanation:
A <--- X <--- B
If A and B have to be upgraded in "lock step" it puts additional constraints on
how X can be upgraded. Effectively, for the purposes of upgrades, it is not "A
and B" that need to be upgraded in lock-step, but "A, B, and X" - i.e.
everything that exists in a dependency chain from B to A. More generally, if
you have a bunch of stuff {P} that needs to be upgraded in "lock step", it is
not {P} but the "cyclic closure" (I don't know what the actual graph-theoretic
term is) of {P} that actually needs to be upgraded in "lock step".
This places a greater constraint on the ecosystem and makes things harder, not
easier - especially if the developer of X does not realise that it has to be
upgraded in "lock step" with A and B, and does not co-ordinate compatibility
releases with the developer of {A, B}.
In this case, cmdliner exists in the cyclic closure of TWO "lock-step-upgrade"
projects, {opam, opam-install; cmdliner} and {topkg, topkg-care; cmdliner}.
This is a further constraint on top of the ones I already mentioned.
> The dust around different solutions for the topkg problem has not
> settled yet: There is a new proposal now:
>
> upstream-opam-fix: Change cmdliner and opam upstream such that
> they can be installed without topkg and without a
> build-dependency cycle.
>
This would be ideal yes, if it's not too much effort. I'd be happy to help with
that.
>> What is the tool that actually generates these .install files? Instead
>> of "opam-installer --script" that converts these files into a script,
>
> I believe it is topkg that generates these .install files. Yes,
> adding installation capabilities to topkg itself is also an
> option. However, the t in topkg stands for transitory, I have the
> impression the plan is to trash topkg in the not too far future
> (maybe opam 2).
>
Well, the suggestion could also apply to whatever replaces topkg, and the code
could simply be copied over in that case.
X
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
