On 2025/03/31 21:09, Florian Viehweger wrote: > > > I've made the suggested changes, however I'm missing something here. > > > > > > According to the documentation only 'main' should be built without > > > arguments. However both versions are built. What am I doing wrong > > > here? > > > > Which documentation? > https://www.openbsd.org/faq/ports/ports.html#PortsFlavors > > * Summary: Some ports are split into several packages. make install will > only install the main subpackage. > > To me this approach in fish seems to me like a subpackage, so I > presumed that it would be handled the same.
It's not a subpackage. I don't think it is exactly described in ports.html but I'd perhaps describe it as a sub-port. For an example of a port with subpackages, see e.g. mariadb - it will have MULTI_PACKAGES in the Makefile, and various PLIST-xxx, each containing part of the built/installed files. This is more like postfix or jdk, where multiple versions of the software are in separate port directories (sometimes sharing build parts via ../Makefile.inc, sometimes not). For a more complicated example see asterisk or php, these have both multiple versions _and_ subpackages. > > These are separate ports, if you are in shells/fish and type "make" > > then it will simply recurse to v3 and main, this is expected. > > > It is expected that both versions will be built; the fiddly bit is > > the placement of the "@pkgpath shells/fish" marker in the PLIST so > > that pkg_add -u works as expected. > > > > Tweaked version attached. > > > > What's the purpose of the gnugetopt run dependency? It doesn't seem > > to be used in either v3 or v4.. > > From what I've seen it is (or was) used to parse long arguments. I did > some testing and tests behave the same without the gnugetopt run > dependency. > > As release is approaching, I'd like to remove the dep from the port > after unlock. I don't want to unknowingly break something for some > users. Absolutely makes sense. > Thank you for already importing the split fish package. > > I've seen that the package is not available in i386 snapshots right now. > I hope this is due the timing of bumping a base lib and the timing of > the build process of the i386 packages. I'll investigate once new > snapshot packages are on the mirrors. I hadn't imported at the time you wrote the mail, but have done so now. It is in the i386 snapshot that I've signed today.
