Re: GENERAL porting advice

[Don Y <dgy%caramail.com@localhost>]

On 12/4/2024 7:56 AM, Greg Troxel wrote:
> Don Y <dgy%caramail.com@localhost> writes:
>
> > E.g., I would think it would be preferable for an author to directly
> > support NetBSD in HIS released sources.  But, that means that he
> > would have to take on the task of verifying his application runs on
> > (some particular releases/architectures) NetBSD at each new release
> > of his codebase.
>
> Yes, the author could do that.  They could also accept patches to make
> it work, submitted by others.   This is true for all upstreams and all
> operating systems they could run on, and isn't special for NetBSD.
>
> You seem to be assuming some particular affirmative testing duty, but I
> don't understand where that comes from.

If I claim my code runs on XYZ, then, presumably, I have tested it on XYZ.
What value to release untested code -- regardless of OS?

> There are a wide range of
> upstream practices about NetBSD support, ranging from hostility to
> deliberate indifference, to accepting reasonable patches if submitted,
> to trying to fix things, to calling for testing of betas on a
> development mailinglist with people with lots of systems, and to
> actually having NetBSD systems as part of CI.  There is no "would have
> to".  There is simply what upstream chooses.

Do you expect an author to test his code AT ALL?  If so, then wouldn't
you expect the conditions under which it is verified to run to be
spelled out?

You expect folks developing *packages* to actually test them, don't
you?  Or, can I just package things up and let someone else worry
about if it even runs?

> > Do you see the difference -- in *who* adopts responsibility for this?
>
> If you want to take on work, just do it - I don't see why you are
> asking.  If you are asking about theoretical responsiblity, I don't see
> that this makes sense to talk about.  Pretty much nobody here has any
> authority to allocate other people's time.

Of course you have no such "authority".  But, if someone assumes
responsibility for a task (e.g., the original author including
support for a particular platform, a package developer doing the
same, etc.) then you expect them to make an honest effort to
actually do what they claim.

> My advice is to try to get fixes upstream, meeting upstream where they
> are, and pushing them gently.

I've reached out to a few of the "developers" to see how amenable
they are to working towards such releases.  Understandably, this
may not be a priority for many.

OTOH, others may be eager to see their code run on other platforms
and be willing to assist with that effort -- if they believe in its
quality.

> > > One is that separate from pkgsrc, any published upstream program (which
> > > releases tarballs or the equivalent), should be written in such a way
> > > that it builds and works on any mostly-reasonable system that mostly
> > > conforms to POSIX, and not doing so is a bug.  Not all upstreams see it
> > > that way, but many are happy to take patches.
> >
> > Most of my applications were written to run on a distributed, capabilities
> > based multiprocessor.  So, they would be considered "bugs" by your
> > (arbitrary) requirement that they be POSIX-compliant.
>
> I congratulate you on pulling a non-relevant example out of a hat.  I
> was referring to the bulk of mainstream software, which is what it
> seemed we were talking about.

Did you perhaps miss this in my original post:
   "others (e.g., those for which I am the author/owner) are
   unsupported on all of the "main" FOSS OSs."
Interactions with an OS are typically not an essential part
of the algorithms embodied in an "application".

In my case (embedded), those applications tend to be designed to
continuously interact with each other and the environment so how
they do that is a key part of their utility /in my application/.

But, others could opt to run batch versions -- if only to understand
how the algorithms work OR adapt them to their own needs.  E.g., I
have a set of applications that interact with "braille terminals"
(refreshable braille displays) to accept input from and drive
output -- translating" on the fly.

It would be hard for me to imagine using them in a batch mode
(a braille note taker?) instead of as the *interactive* input
and output devices they were designed to be.  I.e., they'd want
to be wired INTO a user session atop a vty.

Likewise, speech I/O, speaker identification, diarisation, etc.
for exactly similar reasons.  I don't think pkgsrc even has a category
to address "accessibility" applications!

I would have to evaluate how the utility of the applications can
best benefit folks constrained to an environment like *BSD, etc.
(or, just publish and let others sort out how to make it run on
their platform of choice -- admittedly a higher bar to reach)

> > That doesn't mean that the applications themselves *can't* run under
> > such a system; it just means that the assumptions made in their development
> > would have to be reevaluated for an environment that can't provide those
> > same guarantees.
>
> Most programs are written for mostly POSIX, except that people that only
> use Linux often use Linux-specific non-POSIX interfaces, usually (it
> seems to me) because either they don't realize there is a standard, they
> don't understand the point of standards, or they don't care.  I was not
> discussing (and you didn't either in your first message) programs
--------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> written for environments that are not mostly like POSIX.

I again direct you to my original post.  I tried to make that
pretty clear; they are the sorts of things that can readily
compile (they have been deliberately written to be portable)
but not be of *practical* use, as is.

> > > Well, upstream packages should have tests,
> >
> > "Should" and "do" are spelled very differently, in practice.  :<
>
> I know that.  But if upstream doesn't have tests, and it builds but
> doesn't work, nobody should be surprised, and that's just how it is.  If
> you want to test, fix, file bugs upstream --- great.

Ah, this is what I was missing.  So, all you expect a package to do
is *build*, not necessarily *run* (on the target).  That's a much
lower bar to meet.  OK.

> > I would hate to waste time building a *package* if the preferred solution
> > is to get the author to make the required changes.  So, this changes
> > the primary interactions when making those patches:  do you interact
> > with pkgsrc (and staff) or with the original author.
>
> I think you are missing the point that even if the upstream builds and
> installs perfectly under NetBSD, we still want a package.  It

Sure, but that's a lot easier to get when the author has already done
much of the work -- likely including testing (if HE has built it
there).  Building a package becomes more a technical exercise than
an engineering/development one.

> encapsulates the build instructions and produces a binary installable
> package.  The only difference for programs with portability bugs is
> adding some patches.  Many of the things I package have zero patches, or
> only things to adapt to pkgsrc build norms (where upstream isn't wrong).

Thanks!