Fwd: Re: Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )

[Albert van der Horst <albert@spenarnc.xs4all.nl>]

-------- Oorspronkelijke bericht --------
Onderwerp: Re: Bug#883702: RFS: lina/5.3.0-1  (  #859130 ITP: lina -- 
iso-compliant Forth interpreter and compiler )
Datum: 2018-06-29 19:16
Afzender: Adam Borowski <kilobyte@angband.pl>
Ontvanger: Albert van der Horst <albert@spenarnc.xs4all.nl>

On Fri, Jun 29, 2018 at 12:14:12PM +0200, Albert van der Horst wrote:
> Adam Borowski schreef op 2017-12-21 20:26:
> > On Wed, Dec 06, 2017 at 05:51:50PM +0100, Albert van der Horst wrote:
> > >  * Package name    : lina
> > >     Version         : 5.3.0-1
> >
> > Hi!  I for one don't know the slightest bit about Forth, but as no one
> > has taken this RFS, I can review packaging only -- which, while not
> > ideal, is not a show stopper for uploading.
>
> Hi Adam,
> I direct this to you personnally, because you've been the only
> one reacting to my request for sponsoring, beside Geert Stappers.

Well, I greatly prefer review to be done in public, where others can 
point
out when I get something wrong, where there's a record of suggested 
changes,
and when people can find answers to similar issues.

> May I ask you to review the package in its version 5.3.0-2
> before I repost a new RFS?

Obviously!

> I can promise that there are only "green" remarks.

Heh. :p

> I've no sponsor for the package because Geert Stappers is in fact
> not willing to sponsor lina as defined by the upstream source
> package
> https://github.com/albertvanderhorst/ciforth/releases/download/CVS_REL-5-3-0/lina-5.3.0.tar.gz
> He also wants to have the upstream changed instead of adding Debian 
> patches.
> Note that the upstream is a stable release since two years.

I don't understand this: usually there are changes over upstream, both
Debian-specific or not.  That you wear two hats: both one for upstream 
and
one for Debian packager, doesn't matter.  I for one too carry patches 
for
packages where I'm upstream.

> Geert was only willing to base a Debian
> package on the content of the whole
> https://github.com/albertvanderhorst/ciforth
> which includes building windows and apple programs.

Is it a part of the "generated source" thing?  If so, he's got a point: 
a
Debian source package is required to be the preferred form for 
modification.
Ie, the form that upstream would use, and one that can take patches
submitted by other contributors as-is, without further ifdeffage.

There's no need for adding optional parts of the source, but no harm 
either.

> It also includes (or at least included) 4 auxiliary c-programs, none of
> which should be in a lina distribution IMO.

They do no harm.  While insisting on complete source distribution has 
less
purpose than it had in 1993 when Debian started as people don't rely on
floppies or CD-ROMs to get the sources, there's been quite a few of 
cases of
niche software (and lina is pretty niche...) having their upstream
disappear, leaving no trace other than downstream repositories.

So, while there's no need to go out of your way adding auxiliary stuff,
there's no point trimming tarballs as long as all their contents is 
freely
licensed.

> I don't think that would be a good contribution to Debian, and
> it would take forever to get it right and the package would be
> very hard on my target audience.

"Would take forever to get right" is a good reason, yeah.

> > Your choice of a language to code a compiler is... interesting.  But
> > then, at least it's not node.js, php or python :)
>
> A compiler writer has no choice, all compilers are written
> in assembler (and itself). php and python are merely libraries written 
> in c.
> Besides c there are very few compilers around. This is one.

I haven't yet seen any other compiler written in assembler (I'm a part 
of
the generation that played with decomissioned punched tape in 
kindergarten
but didn't get to use such computers myself).  It's a pretty bad idea -- 
it
takes many times as long to write the same program in assembler than in 
a
compiled language, and the program is not portable.  It looks like arm 
will
dethrone x86 pretty soon -- the architecture is way more efficient, 
Intel no
longer has a process advantage, and even the niche of high-end servers 
is
getting assaulted.  Then there's coming riscv with lofty goals of 
kicking
out both arm and x86, and a list of backing companies that may actually
accomplish that.  Yet your compiler is stuck with i386 while a C program
wouldn't care about the platform.  It's easy to change code generation 
(and
producing bytecode for LLVM or such would grant instant support for a 
wide
array of targets) but porting the compiler itself would need a total
rewrite.


Meow!

--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst