Xiyue Deng <manp...@gmail.com> writes: > Hi Aymeric, > > Aymeric Agon-Rambosson <aymeric.a...@yandex.com> writes: > >> Hello team, >> >> As you may have noticed, Mr. Kimura has opened bug report 1086758, >> in which he claims that elpa-magit should still depend on >> elpa-git-commit (which it does not anymore, since 4.1.2-1). >> >> He is right, of course. The reason dh-elpa stopped adding this >> dependency to elpa-git-commit is due to upstream commit c170fcf3 >> (https://github.com/magit/magit/commit/c170fcf39918e567948fec43b70a592765ed5fe7). >> >> Since this commit, git-commit is distributed by upstream as part >> of magit, which means several things : >> - The Package-Version and Package-Requires headers of git-commit >> have disappeared. This is what prompted me to push commit >> a011f2f1, which in retrospect, does not solve anything (you will >> notice that many of the dependencies of elpa-git-commit have >> disappeared in sid, which is wrong). >> - One line of the Package-Requires header of magit has disappeared >> as well (the one referencing git-commit), which is why the bug >> 1086758 appeared. >> >> Upstream now intends to always distribute magit and git-commit >> together. As Mr. Kimura noticed, magit depends on git-commit. But >> since c170fcf3, the reverse is also true. So we must make sure >> that magit and git-commit are installed, removed and upgraded at >> the same time. >> >> I see two solutions for this, which I wanted to get you opinion on >> before getting started : >> - Remove the binary package elpa-git-commit, and distribute the >> lisp/git-commit.el file as part of elpa-magit. >> - Keep the binary package elpa-git-commit, and add a circular >> dependency between it and elpa-magit (are circular dependencies >> allowed at all ?). >> >> The second solution is easier, and can be reverted if upstream >> decides to revert c170fcf3 somewhere down the road. >> >> I've cced Barak and Matteo, who have made the latest uploads, but >> the questions (particularly what is proper regarding circular >> dependencies) are directed to everyone. >> >> Best, >> >> Aymeric >> > > I guess I should have used a separate branch + MR instead of pushing my > commits implementing solution 1 directly (implying I'm voting for it). > Would still like to see the outcome of this discussion. Please also > feel free to revert my commits if solution 2 is preferred. >
Regarding solution 2: while I do see some people may like it which preserves the current behavior, it looks like circular dependencies would cause issues (see circular dependency discussion at [1]) and should be avoided when possible. P.S. I thought following upstream packaging change as a natural solution and so I just directly pushed the changes. Will use an MR in future. [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
