[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing

Pirate Praveen praveen at onenetbeyond.org
Wed Oct 4 11:35:03 UTC 2017


On ബുധന്‍ 04 ഒക്ടോബര്‍ 2017 02:07 വൈകു, Philip Hands wrote:
> The problem seems to be that Praveen reads that prohibition as implying
> that it is totally OK to do this when not in main.
> 
> This strikes me as equivalent to reading:
> 
>   All men are mortal, 
>   Socrates is a man,
> 
> and concluding that women are immortal.

You are conflating two issues here.

1. Whether packages can be uploaded to contrib temporarily when their
build depends are not in main.
2. Using network during build.

> The correct way to read this bit of policy is that network access during
> build is considered such a bad idea that it is not allowed under any
> circumstances in Debian proper (main).
> 
> That being the case, it is a safe bet to assume that it's a bad idea in
> packages in contrib and non-free too.
> 
> If one wants to vary from that, the reason should be made very clear
> indeed.
> 
> I don't believe that Praveen has provided any real justification for
> needing network access, beyond his opinion that policy allows it.

I did not say I will continue to use network access using build, I
already agreed I will use pre-built binaries instead even though I was
not convinced.

> I suspect that in the particular case of using rollup, it is even worse
> than Simon McVittie eloquently describes in his mail to this thread.
> 
> A quick read of rollup's changelog shows that they have had about 30
> releases since July, that they've recently had a major refactoring, and
> that every release since that refactoring has involved fixing that
> refactoring.
> 
> They had a release within a day of Praveen's changelog entry for the
> package, so it's not completely obvious which version of rollup would
> have been used for the package build, but chances are that he used one
> version, and that within 24 hours nobody, not even Praveen, would be
> certain of being able to reproduce that package because it would then be
> using a new version of rollup to do all the work.
> 
> They've had another release since -- more fixups for the refactoring.
> 
> I'm astonished that Praveen thinks it is sensible to build on these
> shifting sands.  My astonishment is then only magnified at every step:
> 
>   o  When it is pointed out, still not realising the folly of this.

Because the shown folly is only in theory and it is never in practice.
As these packages are always uploaded as binary included and never built
on the buildd (as buildds already prohibit network access during build).
If I include pre-built files, nothing changes in practice and only in
perception, hence I'm not convinced.

>   o  Running to policy, looking for excuses.

Indeed, that is the authoritative source when there is a difference of
opinion.

>   o  Blaming ftp masters for not noticing these flaws.

Indeed they are the people who are supposed to ensure this requirement
of policy.

>   o  Insisting that the TC needs to be involved to fix the mess

Isn't that how differences to be settled when developers can't reach a
conclusion?

> Should we really try to make policy forbid all the foolish ways in which
> one might try to assemble a package, in order to ensure that there is
> nowhere for people to hide in policy?  I think not.
> 
> It would seem much more straightforward to remove the upload rights from
> people who insist on repeating this sort of behaviour incessantly.
> 
> Praveen, please don't do it again.

I think you are showing wrong attitude and acting as if you have more
authority over me/others. You are wrongly pushing an opinion that was
not mine. What I asked was the suitability of being in contrib and not
for using network during build.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20171004/ec009a95/attachment-0001.sig>


More information about the Pkg-javascript-devel mailing list