On 2017-12-24 at 07:02, Albert van der Horst wrote: > Geert Stappers schreef op 2017-12-22 10:18: >> Control: owner -1 ! >>> Also, is this the real source (AKA, "preferred form for >>> modification")? Assembler is a valid language, generated >>> assembler (nor generated shell, generated C, ...) is not. Some >>> parts say about a configuration process that, as it seems to me, >>> expands variables for a particular platform. >> >> <snippet from="ci86.lina.fas of the lina.orig.tar.gz at >> mentors.debian.net"> >> ; If this is a configured assembly file, it should be accompanied with configured >> ; documentation (texinfo, ps, html.) >> ; WITHOUT THE DOCUMENTATION: GIVE UP! GET THE REAL THING! >> ; You have a configured system, if there are NO curly brackets on the next line. >> ; >> ; >> ; Configuration of this particular version: >> ; 32-bits protected mode >> ; running under Linux ; with native forth I/O >> </snippet> >> >> >> So yes, I have the feeling that I'm dealing with generated assembly. >> >> The .orig.tar.gz does have ci86.lina.fas >> I wonder what generated it and from what. >> >> @Albert: Would you please elaborate? > > I appreciate and understand what "prefered form of modification is". > I also understand that Debian must thread carefully here, and not > accept packages that bend the rules. This package certainly doesn't > not go against the spirit of the rules and may only superficially > seem not to obey the letter of the law. This has been discussed > already to some extent. > > There is a choice of assemblers . I've a kind of generic assembler > code, (that is not assembler code that could be assembled by any > assembler) and then an m4 script that transforms it to either fasm, > .s nasm or even tasm or masm format. > > This is *not* generated assembler. The assembler is a genuine > source. There is only a limited processing between equivalent forms, > to present a readable and modifiable source to some one inclined to > modify lina. Although I do not in any sense speak for Debian, my understanding is that the key question is: When the upstream is modifying the code, does the upstream edit the code at hand directly, or does the upstream edit something else and transform the result into the code at hand? If you write code in one form, then programmatically transform it into another form (which is compiled or run by a different tool), but never voluntarily directly edit the second form, the second form is not considered "the preferred form for modification" according to Debian's definitions. Rather, the first form is considered the "source" of the second form. > There is a one to one correspondance between a line with an > assembler instruction in lina.fas lina.s lina.asm lina.nasm and the > preconfiguration system, and they all correspond to the same binary > code. > > The base system also contains code for MS-windows and MSDOS or even > stand alone. This is removed by m4 to present a proper Linux source. > Nothing is gained by drawing all this linux foreign code into a > Debian package, merely to remove it. The more so as this system is > available and GPL-ed in its own right to be used by anybody > interested in e.g. an UEFI system booting directly into Forth. > > Likewise there is also base documentation with an m4 provision to > remove all the MS related documentation for a Linux texinfo file. I > wanted to avoid the situation with the gnu assembler where almost all > options are irrelevant for the processor one is currently working > with. > > So in short it is a matter of configuration and selection, not > generation. From what you describe, it sounds to me as if the preferred form for modification is that "generic assembler code", and people writing patches to send upstream should probably write them against that form of the code. Even if that's not strictly necessary (if, e.g., you're happy to accept patches against the processed-into-a-specific-assembly-language code and have your m4 script convert the patched form back into your generic assembler code so that you can apply the result to your repositories), as long as the form of the code which you actually edit is not the one which you ship, the one you ship is not the preferred form for modification. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature