From: Stuart Henderson <stu@spacehopper.org>
Subject: Re: portimport(1): default to -p/usr/ports and avoid silly error
To: ports@openbsd.org
Date: Tue, 30 Jun 2026 17:15:02 +0100

On 2026/06/30 18:02, Jeremie Courreges-Anglas wrote:
> 
> I import all my new ports with portimport(1), from /usr/ports/mystuff.
> I feel like it's always been the preferred way to run it, and using
> mystuff should be the preferred way to handle *new* ports in general
> (not so much for updates).  Sadly when run from mystuff without
> specifying -p it has always suffered from an annoying error message
> when, right after import, the script tries to cd
> $portsdir/pkgpath-blah and run cvs update:
> 
>   cvs server: failed to create lock directory for `/cvs' (/cvs/#cvs.lock): Permission denied
>   cvs server: failed to obtain dir lock in repository `/cvs'
>   cvs [server aborted]: read lock failed - giving up
> 
> The problem is that $portsdir here is computed from $PWD and thus
> includes mystuff.  The error message is just super unhelpful.
> 
> Fixing this for the common case is easy: use /usr/ports base directory
> for running cvs update after import.  People who use a different
> PORTSDIR can specify -p.  I don't understand how the current
> portimport(1) would avoid puking errors with non-default PORTSDIR
> anyway.
> 
> Test run using an already imported directory.  I just tweaked the
> patched portimport to use cvs -n.
> 
>   ritchie /usr/ports/mystuff/devel/libigloo$ ls /usr/ports/devel/libigloo
>   ls: /usr/ports/devel/libigloo: No such file or directory
>   ritchie /usr/ports/mystuff/devel/libigloo$ diff -u /usr/ports/infrastructure/bin/portimport /tmp/portimport
>   --- /usr/ports/infrastructure/bin/portimport	Tue Jun 30 17:26:34 2026
>   +++ /tmp/portimport	Tue Jun 30 17:51:43 2026
>   @@ -67,7 +67,7 @@
>   
>    read ans?'Does this look correct? [y/n] '
>    if [[ $ans == +(y|Y) ]]; then
>   -	cvs -d$cvsroot import ports/$pkgpath $user ${user}_$timestamp
>   +	cvs -n -d$cvsroot import ports/$pkgpath $user ${user}_$timestamp
>    	grep -q "^@new" pkg/P* && echo "New users/groups, remember to commit infrastructure/db/user.list!"
>    	cd "$portsdir/${pkgpath%/*}"
>    	cvs -d$cvsroot update -AdP ${pkgpath##*/}
>   ritchie /usr/ports/mystuff/devel/libigloo$ /tmp/portimport
>   Package(s) would be named: libigloo-0.9.5
>   Import would go into: ports/devel/libigloo
>   Does this look correct? [y/n] y
>   U ports/devel/libigloo/Makefile
>   U ports/devel/libigloo/distinfo
>   U ports/devel/libigloo/pkg/PLIST
>   U ports/devel/libigloo/pkg/DESCR
>   
>   No conflicts created by this import
>   
>   U libigloo/Makefile
>   U libigloo/distinfo
>   U libigloo/pkg/DESCR
>   U libigloo/pkg/PLIST
>   Don't forget to commit the devel/Makefile when you're done!
>   /usr/ports/devel
>   ritchie /usr/ports/mystuff/devel/libigloo$ ls /usr/ports/devel/libigloo
>   CVS/      Makefile  distinfo  pkg/
>   ritchie /usr/ports/mystuff/devel/libigloo$
> 
> While here, I can't see how rev 1.8 (use of cvs -R) fixed anything so
> let's just revert that.  The diff for the portimport(1) manpage is
> trivial and not included here.
> 
> ok?
> 
> 
> Index: portimport
> ===================================================================
> RCS file: /cvs/ports/infrastructure/bin/portimport,v
> diff -u -p -r1.10 portimport
> --- portimport	19 Feb 2020 17:53:18 -0000	1.10
> +++ portimport	30 Jun 2026 15:26:34 -0000
> @@ -29,7 +29,7 @@ usage() {
>  }
>  
>  user=$(id -un)
> -portsdir=
> +portsdir=/usr/ports
...
> -portsdir=${portsdir:-${PWD%"/$pkgpath"}}

how about this?

portsdir=${portsdir:-/usr/ports}

>  	grep -q "^@new" pkg/P* && echo "New users/groups, remember to commit infrastructure/db/user.list!"
>  	cd "$portsdir/${pkgpath%/*}"
> -	cvs -R -d$cvsroot update -AdP ${pkgpath##*/}
> +	cvs -d$cvsroot update -AdP ${pkgpath##*/}

agreed, -R makes no sense here.

I suppose it could mv ${pkgpath} ${pkgpath}.bak or similar if run from
/usr/ports?