Forwarding the conversation with ftp masters regarding this rejection. *Debian Masters <mailto:ftpmas...@ftp-master.debian.org>* നവംബര് 3
Hi, it is strange that the package Build-Depends: on itself!? Thorsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. *Pirate Praveen <mailto:prav...@onenetbeyond.org>* നവംബര് 3 On വെള്ളി 03 നവംബര് 2017 06:30 രാവിലെ, Thorsten Alteholz wrote: > > Hi, > > it is strange that the package Build-Depends: on itself!? Don't gcc build depend on gcc? node-babel also build depend on itself (it build depends on many of the binaries generated from node-babel source). Babel is a transpiler to convert new versions of javascript to current versions of javascript and they themselves use new versions of javascript for their projects. How do you suggest we fix this? > Thorsten > > > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > > *Pirate Praveen <mailto:prav...@onenetbeyond.org>* നവംബര് 3 On വെള്ളി 03 നവംബര് 2017 10:53 രാവിലെ, Pirate Praveen wrote: > On വെള്ളി 03 നവംബര് 2017 06:30 രാവിലെ, Thorsten Alteholz wrote: >> >> Hi, >> >> it is strange that the package Build-Depends: on itself!? > > Don't gcc build depend on gcc? node-babel also build depend on itself > (it build depends on many of the binaries generated from node-babel > source). > > Babel is a transpiler to convert new versions of javascript to current > versions of javascript and they themselves use new versions of > javascript for their projects. How do you suggest we fix this? The only problem I see is the need for a binary only upload to bootstrap. Since it is an arch:all package, it won't affect bootstrapping new architectures. Did I miss any problems? Can you share links to previous discussions/policy/other docs that explains the problems with build depending on itself? There are similar issues that lintian catches about dependencies like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876016 (circular dependencies). *Praveen A <mailto:prav...@debian.org>* നവംബര് 10 [dropping the list] If this is the final/official/team decision of ftp masters, I'd like to challenge this with ctte as I think it is making the requirement for a package in main extremely difficult and beyond what policy mandates. While I agree this may be a nice thing to avoid build depending on itself for transparency, I don't agree this is reason enough for a rejection as per policy. Moreover, the actual compiler/transpiler used here is a different package and the output is in source code form (not binary or minified or unreadable). Other possible solutions include using a different transpiler like buble or possibly updating nodejs so it natively supports the javascript version used in node-babel-preset-env. *Thorsten Alteholz <mailto:alteh...@debian.org>* നവംബര് 10 On Fri, 10 Nov 2017, Pirate Praveen wrote: > [dropping the list] > > If this is the final/official/team decision of ftp masters, I rejected the package, so first of all it was my decision. Nobody else complained, so either nobody cared or everybody agreed with me. > I'd like to challenge this with ctte as Do whatever you think is best for you and your packages. > I think it is making the requirement for a > package in main extremely difficult and beyond what policy mandates. So all packages have problems bootstraping them into main? I don't think so, at least your mentioned gcc does not have such problems. > While I agree this may be a nice thing to avoid build depending on > itself for transparency, I don't agree this is reason enough for a > rejection as per policy. Please have a look at policy 2.2.1: (...)the packages in main must not require or recommend a package outside of main (...) and the reject-faq[1] in section "Non-Main" > Other possible solutions include using a different transpiler like buble > or possibly updating nodejs so it natively supports the javascript > version used in node-babel-preset-env. Ok, so why don't you just use these solutions? Thorsten [1] https://ftp-master.debian.org/REJECT-FAQ.html *Praveen A <mailto:prav...@debian.org>* നവംബര് 10 On വെള്ളി 10 നവംബര് 2017 04:37 വൈകു, Thorsten Alteholz wrote: > > > On Fri, 10 Nov 2017, Pirate Praveen wrote: > >> [dropping the list] >> >> If this is the final/official/team decision of ftp masters, > > I rejected the package, so first of all it was my decision. Nobody > else complained, so either nobody cared or everybody agreed with me. > >> I'd like to challenge this with ctte as > > Do whatever you think is best for you and your packages. I have taken it to ctte https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881339 > >> I think it is making the requirement for a >> package in main extremely difficult and beyond what policy mandates. > > So all packages have problems bootstraping them into main? I don't > think so, at least your mentioned gcc does not have such problems. > Many packages have, like node-babel, node-babylon and jison. Does gcc use a different compiler to build? >> While I agree this may be a nice thing to avoid build depending on >> itself for transparency, I don't agree this is reason enough for a >> rejection as per policy. > > Please have a look at policy 2.2.1: > > (...)the packages in main must not require or recommend a package > outside of main (...) > > and the reject-faq[1] in section "Non-Main" It does build with itself with an initial bootstrapping, just like how node-babel, node-babylon or jison was bootstrapped with a first binary included upload. > >> Other possible solutions include using a different transpiler like buble >> or possibly updating nodejs so it natively supports the javascript >> version used in node-babel-preset-env. > > Ok, so why don't you just use these solutions? > Because it is a question of policy and not just one package. I will have to do the same for multiple packages. Also it means I have to diverge from upstream build system and maintain it myself without support from upstream for a reason I am not convinced is worth the extra effort. > Thorsten > > [1] https://ftp-master.debian.org/REJECT-FAQ.html >
signature.asc
Description: OpenPGP digital signature
