Re: GENERAL porting advice

[Greg Troxel <gdt%lexort.com@localhost>]

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?

  - is there a pkgsrc entry that wraps the build?

> 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.

> 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/

> 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.  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.
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.

> How (and who) will support for other architectures be verified?

It won't really, unless somebody tries.  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.

> 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, 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:

  - 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.