Preferred source: a fundamental question was Re: - #859130 ITP: lina
- To: Debian Mentors <email@example.com>
- Subject: Preferred source: a fundamental question was Re: - #859130 ITP: lina
- From: Albert van der Horst <firstname.lastname@example.org>
- Date: Mon, 03 Jul 2017 13:34:38 +0200
- Message-id: <[🔎] email@example.com>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
Gianfranco Costamagna schreef op 2017-06-29 20:32:
we want everything built from the "preferred source of modification".
So, if you develop your tool by changing assembly code this is
I do, but there is hitch.
Imagine a Russian scientist with an important FORTRAN package
meticulously documented in Russian because he really doesn't know
English. (If you think that unlikely make it a Chinese).
The preferred source of modification *for him* is this file.
He has made a tool to use "Google Translate" to make an English
version because without understanding the comment the value
is severely degraded.
This is of course in the spirit of open source, and it is the
"preferred source of modification" for the *target* audience.
This is a far cry from a company that obfuscates its source by
replacing all identifiers by random names, a situation where this
rules is intended for.
Will Debian reject the English package?
Would Debian remove it if only aftwerwards
it became clear that this is not the *prefered source*
for the *author*? After all he could have kept it a secret and
nobody would have known, and applauded his attempts at crappy english.
I ommited a small detail of my workflow.
I really program in assembler in the sense that a modification is a
modification to an assembler instruction. Now, all assembler
representations of a program are equivalent, but they differ greatly as
a text, depending on the assembler tool used. E.g. a .s and an .nasm
file are differing in virtually all lines, on account of the comment
symbol alone. It is a pain in the ass to use an assembler you're not
What I do is I have an internal representation, that can be rendered as
.s and as .nasm. 1]
If I publish the program as open source in the context of Debian, I give
out the .s file because I honestly believe that the "preferred source of
modication" for a Debianist is the native gnu assembler format. I myself
change the master file in order to be able to deliver a service to those
who prefer nasm.
For those not versant with assembler. The binary that is generated is
supposed to be byte for byte the same with both assemblers. If not it is
a bug. The sources are equivalent, the binaries are the same, it really
is the same program.
Note, that I could not have told that I use an internal representation
and nobody could have guessed (nor benefited.)
So is the .s accepted as source conform Debian policies?
1] And more. But that doesn't make it fundamentally different.
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst