Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)
On Thu, 22 Feb 2018, Wookey wrote: ... > Anyway, Pirate - I suggest you ask about this on debian-devel where we > can have a pulic discussion about policy and whether there is anything > special about this case which makes it not suitable software for the > archive. This would probably have been a much better approach than the course that was taken. The private discussion with Thorsten that was forwarded to the bug seemed not to have been followed through to any sort of conclusion before escalation to the TC. Also, the questions that Don was trying to explore about why there was a need for the dependencies in the first place went unanswered. Presumably because the whole thing is moot now that the package has been accepted. If that was the reason for not responding to Don, it would have been polite to close the bug at that point. If on the other hand one is still expecting clarification on some outstanding point (despite the fact that the original purpose of the bug is now gone) then it would probably be wise to say so explicitly. In the absence of any of that, my only regret is that we didn't reject the bug at the outset for not really having bothered with steps 1-3 here: https://www.debian.org/devel/tech-ctte I'm confident that we can all learn from this experience, and hope we will do a better job next time. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)
On 2018-02-22 11:59 +, Ian Jackson wrote: > Margarita Manterola : > > Thus, we are closing this bug now, as it's not actionable. > > > > We suggest that you work together with the FTP Masters in > > figuring out a solution to this problem. > > I'm not sure I agree with this. Me neither. (I mean maybe it's true that the TC cannot overrule the FTPmasters, but they can provide technically sensible advice). I don't see any difference between this js package and many other packages in the archive which self-bootstrap or otherwise circularly depend on themselves. So I don't see why this one is not acceptable, and thus so far as I can tell the FTP master was wrong to reject it, or at the very least we should be discussing this issue in terms of policy. It seems to me that a discussion on debian-devel would have been sensible before asking the TC to rule, but as they haven't, it's still sensible. We have plenty of expertise about circular dependencies, especially amongst those involved with cross-building and bootstrapping, where they are more obvious than in normal practice. We could clearly do a better job of formalising meta-data or mechanisms for software that has this characteristic, and we can try to persuade upstreams to do less of it where possible, but self-dependency (at both same and older versions) also occurs more frequently when cross-building or bootstrapping and is not necessarily wrong or bad (self-dependency at the same version is much more of a problem than self-dependency at older versions). Anyway, Pirate - I suggest you ask about this on debian-devel where we can have a pulic discussion about policy and whether there is anything special about this case which makes it not suitable software for the archive. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)
Margarita Manterola : > I'm sorry this took so long to be actioned by us. This is on me. > > In previous bugs that have been raised to the technical committee > it has already been discussed and agreed that the technical > committee does not have the power to overrule official Debian > delegates. This covers the decisions taken for example by the > FTP Masters or the Release Team. > > Thus, we are closing this bug now, as it's not actionable. > > We suggest that you work together with the FTP Masters in > figuring out a solution to this problem. I'm not sure I agree with this. Firstly, it's not clear that the acceptance or not of packages is a decision "for whom noone else has responsibility" in the words of the Constitution ? (That's funny wording because it should say "for which" since decisions are not people...) Secondly, the request could be actioned by a non-binding statement by the TC. Thirdly, when you decline a complaint, I think the TC should give real information about escalation routes. "Work together with the FTP Masters" is not the correct escalation route. You should have advised Pirate that: * Pirate should first escalate the matter with leader@d.o, because although the DPL does not have the power directly to overrule the ftpmasters, the DPL _does_ have ultimate responsibility for the ftpmaster team and therefore does have a supervisory role. * If that does not yield an appropriate outcome, Pirate has the option of a General Resolution. * Alternatively, this could be seen as a question of policy. It seems unlikely that ftpmster would act cotnrary to a clear statement in Debian Policy about when circular build-deps are acceptable. I wouldn't be saying all of this if I agreed that Pirate's complaint is without merit. I think our general approach to circular build-dependencies needs to be clarified. Personally for example I think it's quite ridiculous that the only way to get from the Haskell binaries in jessie to the Haskell binaries in stretch is an undocumented chain of recompilations of packages from snapshot.d.o. If we let Haskell do that, why are we being so hard on JavaScript ? Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
