Re: GENERAL porting advice

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

On 12/3/2024 6:21 PM, Greg Troxel wrote:
> Don Y <dgy%caramail.com@localhost> writes:
>
> > I have several applications for which NetBSD ports do not exist.
> > Some have ports to other OSs available (often buggy); others
> > (e.g., those for which I am the author/owner) are unsupported
> > on all of the "main" FOSS OSs.
>
> There are two separate issues:
>
>    - will the program, when following the build instructions, build and
>      run on NetBSD?

No (esp if, by "run", you mean "run as intended")

>    - is there a pkgsrc entry that wraps the build?

No, in most cases.

> > I've searched the NetBSD.org and pkgsrc.se sites but haven't found
> > any guidelines for bringing something new into the collection.
> > Most (all?) of the information, there, seems to involve /using/
> > (or updating) the existing collection -- even the description of
> > how to create a new entry.
>
> I am not following.  The pkgsrc guide indeed has sections.  Broadly,
> there is how to build and use packages, update an existing package to a
> new version, and how to create a package for program, when there is no
> package yet.

My question addresses the issues BEFORE that point.

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.

This also means there can be a disconnect if his release hasn't changed
but NetBSD has (i.e., verifying the "old, existing" release still works
in the context of the new NetBSD release)

> > What is the generally accepted practice for making these available
> > to NetBSD/amd64 users?  (I run 9.1R and have no need nor desire to
> > upgrade so that's the second problem, after the architectural choice)
>
> The best practice for new people to participate in creating pkgsrc
> packages is to get an account in wip and start doing it.
>
>    https://www.pkgsrc.org/wip/

Again, that skips over the above step and assumes the original
author has no interest in supporting NetBSD directly.  Even if his
code builds (and runs) AT a given release ON a given (OS) release.

Do you see the difference -- in *who* adopts responsibility for this?

> > Is it best to work with the original authors of the applications
> > and encourage them to include my diffs to enable this support in
> > their original distributions?  Or, is it easier/more practical to
> > deal with their current, published releases and patch those
> > after-the-fact?
>
> There are two separate things to do.
>
> 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.

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.

> So, if there is some
> program that you think you want to use or help make available, and it's
> not in pkgsrc, then get the sources, read the instructions, and build
> it.  You may need to point it at prereqs built in pkgsrc with -I and
> -L/-R.  Make fixes and submit them and file bugs.
>
> The second thing is that you can create a package in wip that wraps the
> build, and you can fix problems with patches in pkgsrc.  The pkgsrc
> guide documents our norm that if you add patches that you 1) provide a
> comment explaining them 2) file an upstream bug report and 3) include
> the upstream bug report URL.  The point is that fixes for upstream bugs
> below upstream so that a) they don't need to be managed while updating
> and b) people who build the program on NetBSD not on pkgsrc, and those
> who are trying to build it on OtherBSD, have the benefit of the fixes.

Yes.  (I've experience with pkgsrc in the past -- running NetBSD for
30 years, now)  My point was in WHERE the changes should be introduced
(given that my primary goal is just NetBSD/amd64 support -- even though
most of MY code runs on ARM)

> As an example, often when something doesn't build, looking for #ifdef
> FreeBSD often results in finding things to extend to || defined(NetBSD),
> and sometimes where upstream should have said "not linux" instead.

Yes, been there, done that.

> > How (and who) will support for other architectures be verified?
>
> It won't really, unless somebody tries.

Ah.  OK.

> If you know that a package is
> architecture-specific you can mark it (BROKEN, usually, because unless
> it is support for some arch-specific cpu feature, it's a bug to not work
> on some other system).  We are ok with this deferred evaluation.

But, how do you indicate that it hasn't been BUILT on a particular
architecture?  I.e., it COULD work but noone (i.e., me) has tried it?

> > I assume it prudent to run the applications "for a while" to
> > increase the chances of stumbling on porting problems (assuming
> > the applications have no specific problems of their own :> )
> > before releasing them "into the wild" -- because few applications
> > have formal test suites.  (and, that period should vary with the
> > complexity of the application)
>
> Well, upstream packages should have tests,

"Should" and "do" are spelled very differently, in practice.  :<

> and you can run them when
> building by hand, and you can hook them into pkgsrc.   If you create a
> package and it works for you, it's ok to publish it in wip, and for that
> to be hoisted to main pkgsrc.
>
> It seems like you are overthinking this.  Just:

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.

An author concerned about having his codebase run on as many platforms
as possible would likely welcome said patches -- he just hasn't had the
time/resources to make them, himself.  Burying them in pkgsrc is a
disservice to him.

OTOH, as many authors (esp code that isn't actively maintained) don't
have those resources, interactions with them are likely a waste of effort.

"You should support BeOS!"  :-/

>    - look at upstream tarballs without pkgsrc, build them, fix bugs
>      (including portability) and try to get them fixed upstream
>
>    - if things are useful, create a package in wip
>
> > [Please reply to list as this account uses a whitelist filter]
>
> I expect that if I send a private reply to someone who posted to a list,
> they will get it.   You might seed your filter from the last 6 months of
> posting to thie list, if you're going to do that.