On 2025/08/28 16:24, Marco van Hulten wrote:
> On Thu, 28 Aug 2025 13:22:15 +0100 Stuart Henderson wrote:
> > On 2025/08/28 13:16, Marco van Hulten wrote:
> > > On Thu, 28 Aug 2025 11:08:35 +0200 Marco van Hulten wrote:  
> > > > Hello,
> > > > 
> > > > I have written a port that builds fine (and 'make test' and 'make fake'
> > > > are successful), but package installation fails:
> > > > 
> > > > 
> > > > mvanhult@detekti:.../geo/eccodes$ make install
> > > > ...
> > > > Link to /usr/ports/packages/amd64/ftp/eccodes-2.44pre.tgz  
> > > > ===>  Verifying specs: aec sz gfortran>=8 quadmath
> > > > ===>  found aec.0.0 sz.0.0 gfortran.8.0 quadmath.3.0
> > > > ===>  Installing eccodes-2.44pre from /usr/ports/packages/amd64/all/    
> > > > 
> > > > eccodes-2.44pre (processing)|...
> > > > 
> > > > can't extract share/eccodes/definitions/bufr/tables/0/local/8/78/1, it's not a file
> > > > pkg_add: Installation of eccodes-2.44pre failed, partial installation recorded as partial-eccodes-2.44pre
> > > > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2266 '/var/db/pkg/eccodes-2.44pre/+CONTENTS': @/usr/bin/env -i PKG_TMPDIR=/var/tm...)
> > > > *** Error 2 in /usr/ports/mystuff/geo/eccodes (/usr/ports/infrastructure/mk/bsd.port.mk:2712 'install': @lock=eccodes-2.44pre;  export _LOCK...)  
> > > 
> > > As per sensible suggestion from Stuart, port (WIP) attached.  
> > 
> > thanks.
> > 
> > this collection of dirs and links would likely to be a problem for
> > updates anyway - pkg_add doesn't cope well with a path that changes
> > between link/dir.
> > 
> > package(5) says this about the @symlink annotatiom,
> > 
> > @symlink name                                                             Added after a file entry by pkg_create(1) to record               that the entry is actually a symbolic link.
> > 
> > I suspect this may specifically want a file (as opposed to a file/dir)
> > to try to avoid some cases where people run into the above problem with
> > uodates.
> > 
> > I don't think we have any way to work around that.
> 
> If I understand correctly, this means that we should not have symlinks
> with directories as the targets.  Should I ask upstream to ask if it's
> possible not to have symlinks to directories?

It would be simpler to flatten the tree, I expect this or something
similar will probably work

post-install:
	mv ${PREFIX}/share/eccodes/definitions ${WRKDIR}/
	cp -RH ${WRKDIR}/definitions ${PREFIX}/share/eccodes/definitions