Hi Scott,
Am Fri, Aug 18, 2023 at 01:15:18PM +0000 schrieb Scott Kitterman:
> On August 18, 2023 1:04:26 PM UTC, Andreas Tille <andr...@an3as.eu> wrote:
> >> In Debian terms, it's not the preferred form for modification, so it's not
> >> source. In this regard DFSG goes farther than some software licenses.
> >
> >I think the point Jeroen wanted to make is that these are actually
> >source file archives which "by chance" are featuring a .whl extension
> >rather than a .zip extension.
>
> A wheel is not the preferred form for modification. They're not wheels by
> chance at all.
Yes, thanks to Jeroen's hint I realised this as well and I agree that
this is a nasty way to hide the fact that the files are actually source
archives.
However, you confirmed yourself that future_fstrings is an exception and
comes with source and thus does not violate DFSG. The only difference
I personally can see is that the archives are just hiding what they are.
We could simply add do some
for whl in *.whl ; do ln -s $whl $(basename .whl).zip ; done
and we have source archives that are obviously what they are.
> From a DFSG perspective,
Hmmm, the only thing where I can draw a violation of the DFSG is that
there are no d/copyright entries for the source code that is hidden
inside these *.whl files. Otherwise its "just" duplicated code (in most
cases) which is definitely not nice but IMHO not a violation of DFSG.
> the most straightforward approach is to build-depend on the relevant Debian
> packages and build any needed wheels from that.
Do avoid source code duplication I'm willing to do that. Yes, I
perfectly agree that its pretty ugly (I'm just a bit unsure about
the DFSG violation). I'm wondering whether a simple
zip whl.zip /path/to/python/files ; mv whl.zip whl.whl
will be something that can replace the current packages. I think
we also need to patch the tests to fit the version numbers (if
we do not want to cheat and simply use the version numbers of the
original whl files to avoid patching).
> It won't necessarily get you the same version as upstream uses, but it's
> definitely DFSG compliant.
We also might symlink our resulting whl files with the version number
pdm upstream might expect in their tests. The question is, whether all
this effort might break the tests in some way and we might end up with
endless patching by at the same time loosing the chance to discuss with
upstream. But it might be time to discuss the issue with upstream
anyway.
Kind regards
Andreas.
--
http://fam-tille.de
