Hi,
Post by Serafeim (Serafi) Zanikolas[forking to -devel]
Probably adequate is the logical place for this test, but adequate
doesn't build/run on ports architectures since it moved to golang,
so piuparts should probably keep its tests on those arches until
adequate moves to a more portable language or golang gets ported.
that's because unsupported ports architectures have not caught up to go 1.21,
which was released ~1.5 year ago. I'd claim that that says more about the
viability of those ports, than the suitability of go for Debian tooling.. if you
feel strongly otherwise, I'd be happy to continue this discussion with a wider
I dont feel strongly about this, but I'd like to point out that I
disagree. IMO it was wrong to rewrite adequate (as any central QA tool
for Debian) in a language which is not available *everywhere*.
I'd like to discuss this with a focus on general principles, and only discuss
specifics (adequate, golang) to the extent that it helps reason about general
principles.
so we have a qa testing package that was written 11y ago in perl, and has been
orphaned for almost all of that time (10y!). it's not critical but it does serve
a purpose, and it's therefore nonideal that it's been orphaned for so long.
someone takes it over and rewrites it in a language that runs in all supported
arches, and likely in many ports too as long as they keep up with a relatively
recent version of the language (in this case, a version released 1.5y ago).
My 2 cents, as an ex m68k porter:
There is always work to be done to support an architecture. In Debian,
most of that work goes to
- Making sure the kernel works
- Making sure gcc works
- Making sure binutils work
- Making sure libc works
This doesn't cover everything, but it covers pretty much 75% of the
work of keeping an architecture alive.
Any language that builds on that work makes it more likely that it will
be supported by all Debian architectures, including less popular ones as
well as future ones that still need to be bootstrapped.
Porting a language such as golang to a new architecture is a fairly
significant undertaking, as it requires that you redo much of the work
that had already been done while porting libc, as golang chose to have
their own syscall interface and ABI rather than reusing the libc one
(presumably for good reasons, I have no idea; regardless it's orthogonal
to the point I'm trying to make). This is true not only for golang, but
also for all compilation and/or runtime environments that require
architecture-specific work.
Yes, some architecture maintainer can work on the required patches, but
there are only so many of them and they don't have infinite time for all
the compilation and runtime environments out there that require
architecture support, and they also may not have the required skill set
to do this work for each of them. So sometimes the work gets postponed
until the architecture has more users and then someone gets annoyed
sufficiently to do the work, or the maintainers of the language
environment see the architecture no longer as fringe and do it
themselves.
Sometimes patches for your architecture are difficult to submit; e.g.,
at some point the LLVM project was notoriously bad at accepting porter
patches for architectures they considered fringe or otherwise
uninteresting, making use of LLVM-based runtimes and languages only
implemented in LLVM (e.g., rust for much of its lifetime) problematic on
those architectures. I have not followed along with LLVM in recent
years, perhaps this situation has been resolved, but again this is not
core to the point I'm trying to make.
With that background,
If you write something for the project, I think you should totally
choose the language that you're most familiar and comfortable with.
Sometimes that means disappointing people using architectures on which
your language of choice is not available. That's fine, provided you're
not trying to replace or implement a core component of Debian.
If you're trying to write something that eventually should be running on
*every* Debian system out there, then please, for the love of all that
is important to you, don't use something that requires specific porter
work. But outside that constraint? Do whatever makes you most
productive.
I did that when I chose perl as the language to write extrepo; knowing
full well it's not as popular as it once was, I still decided that I
could work with that most easily and that it would be much more
efficient, *for me*, if I chose that language to write extrepo in.
And you should absolutely do the same.
--
***@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.