On 2021/03/03 07:27, Greg Steuck wrote: > On Wed, Mar 3, 2021 at 12:32 AM Stuart Henderson <[email protected]> > wrote: > > > > Validated to be reasonable by building devel/sqlports. I take the > > > success of sqlport rebuild as evidence that no dependency edges are > > > left hanging. > > > > I don't think sqlports cares that a port is unhooked when calculating > > dependencies, if the directory exists it can enter it. > > > > So if anything still retained references my query would've shown a hit?
Say you have ports/cat/port1 ports/cat/port2 ports/Makefile has port1 port1 depends on port2 sqlports will generate records for FULLPKGNAME=cat/port1 including the dep on cat/port2, but it won't generate records for FULLPKGNAME=cat/port2. If you want to be more sure then you can do a sqlports build with the ports actually removed rather than unhooked, then a forgotten dep will cause it to error out as make recurses into a nonexistent dir; but... > > > I ran this query to confirm no hs- ports are left: > > > > > > % sqlite3 /usr/local/share/sqlports > > > sqlite3 /usr/local/share/sqlports > > > SQLite version 3.34.1 2021-01-20 14:10:07 > > > Enter ".help" for usage hints. > > > sqlite> SELECT FULLPKGNAME,COMMENT FROM Ports WHERE FULLPKGNAME LIKE > > 'hs%'; > > > SELECT FULLPKGNAME,COMMENT FROM Ports WHERE FULLPKGNAME LIKE 'hs%'; > > > > Can you check this? > > > > select distinct fullpkgpath from depends where dependspath like "%/hs% > > > > Indeed, this is a better query and it returns an empty result. ...it sounds like this will be OK.
