Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)

[Philip Hands]

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)

[Wookey]

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)

[Ian Jackson]

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 Jackson    These 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.