On 7 October 2021 3:02:55 am IST, Thomas Goirand <zigo@debian.org> wrote:
On 10/6/21 6:53 PM, Pirate Praveen wrote:
On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, Jonas Smedegaard > <jonas@jones.dk> wrote:
Quoting Yadd (2021-10-06 11:43:40)
On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:I find the severity accurate: Relying on non-source code is a severe
Source: src:node-lodashHi,
Version: 4.17.21+dfsg+~cs8.31.173-1
Severity: serious
Justification: do not compile from source
;
Dear Maintainer,
;
The vendor directory should be emptied
;
The debug version is compiled without source (lintian warn)
and moreover the rest of file are already packaged
;
grep -R vendor * gives only a few hit that could be cured by
symlinking
;
Bastien
this files are used for test only, maybe severity could be decreased. >>>
violation of Debian Policy, not matter the purpose of relying on it.
I think we should change the policy here. Running tests helps improve
the quality of the software we ship. Many times the vendored code is
used to ensure the code does not break in a specific situation. I don't
think reducing test coverage in such situations is really helpful.
Right, running tests helps improve the quality of software we ship.
Which is why you probably need to test using what's shipped in Debian >rather than using a vendored source-less code.
We are not shipping the source less code. This is used only during
tests. I don't think we are not gaining anything by removing tests
here. Just making it harder for the package maintainer to run tests.
If we rely on non-free code for tests, that's really bad too, and that
must be avoided just like we're avoiding source-less code everywhere
else in Debian. The policy shall not change, please.
The code is not non-free here, just a specific version of a Free
Software code built outside Debian.
I think tools required for tests should be considered separately from
tools required to compile. I think it should be treated similar to
test data.
I think blindly applying a rule without thinking of any consequences is bad too.
I think a nocheck build profile which excludes these files from build
is sufficient...
The current policy is not making Debian better.
I haven't looked into the specifics of this situation, but in general,
tests should be run against the same versions of dependencies that the
actual code will use, for what should be obvious reasons. If Debian has
the dependencies with different API versions, then it's all the more important that the tests run against the Debian versions of the
dependencies.
What you are proposing would require the package maintainer to adapt these tests to versions available (many times with different API versions) in Debian and the easier choice is disabling tests.
Richard Laager <rlaager@debian.org> writes:
I haven't looked into the specifics of this situation, but in general,
tests should be run against the same versions of dependencies that the
actual code will use, for what should be obvious reasons. If Debian has
the dependencies with different API versions, then it's all the more
important that the tests run against the Debian versions of the
dependencies.
I believe the dependencies in question are test dependencies. In other words, they're dependencies required to drive the test suite machinery,
not dependencies of the code under test.
Right: It is ok to use upstream-provided pre-minified code, as long as
that code is DFSG-free, which requires the source of that code must
exist in Debian.
...and because that is often complicated to ensure (not because it
violates DFSG in itself), it is easier to avoid upstream-provided pre-minified code.
On 10/7/21 11:35 AM, Russ Allbery wrote:
Richard Laager <rlaager@debian.org> writes:
I haven't looked into the specifics of this situation, but in
general, tests should be run against the same versions of
dependencies that the actual code will use, for what should be
obvious reasons. If Debian has the dependencies with different API
versions, then it's all the more important that the tests run
against the Debian versions of the dependencies.
I believe the dependencies in question are test dependencies. In
other words, they're dependencies required to drive the test suite machinery, not dependencies of the code under test.
Thanks for the clarification of the specifics!
In that case, I personally don't see a big problem with them being
vendored as opposed to using system copies.
But AFAIK, they do still need to be DFSG-free to be in main if they
are in the source tarball. And I personally would not consider
minified JS (if that is indeed at issue here) to be "source code".
Jonas Smedegaard <jonas@jones.dk> writes:
Right: It is ok to use upstream-provided pre-minified code, as long
as
that code is DFSG-free, which requires the source of that code must
exist in Debian.
...and because that is often complicated to ensure (not because it
violates DFSG in itself), it is easier to avoid upstream-provided
pre-minified code.
Test suites are often a licensing mess. Another common case that's
not in
play here but that I've seen before is that long-standing projects
that
have been used commercially often have test snippets with unclear
licensing that check for regressions that were previously seen in
proprietary environments.
Debian historically has erred on the side of maintaining clear source availability and licensing status for everything in Debian (which
includes
everything in any source package) at the cost of not availing
ourselves of
test suites that would otherwise be useful. That's unfortunately
probably
the easy path here as well, until someone has time to find
non-minified
versions of the test dependencies and either package them or include
them
in the package. It's frustrating to remove the tests, but the DFSG
source
requirements as currently applied do not distinguish between code
shipped
only in source packages and code also shipped in binary packages.
I can see an argument that we should not worry about minified files in
main that are (a) only in the source package and not in any binary
package, and (b) only used to run tests, not to build the binary
packages.
(I'm not saying I agree or disagree, just that I can see the
argument.)
But given the apparent consensus on this in past discussions, I
suspect
that changing that rule would be GR material rather than debian-devel
thread material. Making that sort of change without a GR to be sure
the
project is behind it feels like the kind of thing that's likely to
spawn
endless arguments that will sap everyone's will to live.
Draft text for the GR (this is my first time proposing a GR text, so
help is welcome to make the text clearer).
We should not worry about minified files in main that are (a) only in
the source package and not in any binary package, and (b) only used to
run tests, not to build the binary packages.
To ensure these are not used during generation of binary packages, a
nocheck build profile should be provided which will remove these files
from the build environment.
Rationale: Most of the time these minified files create a specific
instance of a test case and these tests are not the only way to ensure functionality of the code we ship. Even though upstream runs these
tests, during transitions we deviate from upstream for runtime
dependencies and a way to ensure the functionality is not broken by a dependency change is essential. Insisting these test cases are built
using only packages in main just makes running tests harder and
disabing tests is choosen as an easier option. Treating the code used
to run only tests is the same as generated code we ship is not useful.
In case of the code we ship missing sources, our users can't modify the software. But if these sourceless code is used during tests, only
ability to modify the test cases is lost. A test case is an arbitrary combination of the code and we have many different ways of testing a
code.
Option 1: Agree, we should allow these files in main
Option 2: Disagree, we should not allow these files in main
Option 3: Further discussion
Draft text for the GR (this is my first time proposing a GR text, so
help is welcome to make the text clearer).
We should not worry about minified files in main that are (a) only in
the source package and not in any binary package, and (b) only used to
run tests, not to build the binary packages.
To ensure these are not used during generation of binary packages, a
nocheck build profile should be provided which will remove these files
from the build environment.
Rationale: Most of the time these minified files create a specific
instance of a test case and these tests are not the only way to ensure functionality of the code we ship. Even though upstream runs these
tests, during transitions we deviate from upstream for runtime
dependencies and a way to ensure the functionality is not broken by a dependency change is essential. Insisting these test cases are built
using only packages in main just makes running tests harder and disabing tests is choosen as an easier option. Treating the code used to run only tests is the same as generated code we ship is not useful. In case of
the code we ship missing sources, our users can't modify the software.
But if these sourceless code is used during tests, only ability to
modify the test cases is lost. A test case is an arbitrary combination
of the code and we have many different ways of testing a code.
Option 1: Agree, we should allow these files in main
Option 2: Disagree, we should not allow these files in main
Option 3: Further discussion
But if these sourceless code is used during tests, only ability to
modify the test cases is lost.
A test case is an arbitrary combination of the code and we have many different ways of testing a code.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 85:22:59 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,099 |
Messages: | 5,276,971 |