Re: pkgsrc package information problem

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

oskar%fessel.org@localhost writes:

>> Jan-Hinrich Fessel <oskar%fessel.org@localhost> writes:
> dweezil# grep wget libpsl-0.21.2/*
> libpsl-0.21.2/+CONTENTS:@blddep wget-1.21.3nb2
> libpsl-0.21.2/+REQUIRED_BY:wget-1.21.4
>
>> It seems ok to record this as a dependency that *was used to build the
>> package*.  
>
> I tend to disagree, it was not used to build the package, it was used to fetch the sources.
> And worse, in the past i stumbled upon cases where rebuilding any packet was triggered by updating wget.  That is clearly not what i desire to do.

It depends on what you mean by build, really.   The tool is used by
'make package' from nothing.

Overall, it seems just as reasonable to list digest as a blddep as wget.

>> That is different from a dependency that *will be used to
>> build the package*, which pkg_rr obtains via
>> 
>>        bdeps=$(/usr/bin/env ${MAKE_SET_VARS} ${MAKE} show-depends VARNAME=BUILD_DEPENDS)
>>        tdeps=$(/usr/bin/env ${MAKE_SET_VARS} ${MAKE} show-depends VARNAME=TOOL_DEPENDS)
>>        rdeps=$(/usr/bin/env ${MAKE_SET_VARS} ${MAKE} show-depends)
>
> It does, but before that it does:
>         echo "${OPI} Checking if $pkg has new depends..."
>         OLD_DEPENDS=$(${PKG_INFO} -Nq $pkg | sed 's/-[0-9][^-]*$//')

Thanks; I didn't realize this.  I had thought pkg_rr only got full
depends from binary packages, and then BUILD/TOOL from source.  That is
perhaps a bug.  I have come to think that it's probably best to make one
pass over all installed packages to get the information.  Now I think
that should be

  full deps from installed packages (because make replace will dirty a
  depending package, whether or not building that package from source
  will still depend)

  full/build/tool from source

and this omits build/tool from installed.

> dweezil# pwd
> /usr/pkgsrc/www/libpsl
> dweezil# make show-depends VARNAME=BUILD_DEPENDS
> dweezil# make show-depends VARNAME=TOOL_DEPENDS
> python311>=3.11:../../lang/python311
> libtool-base>=2.4.2nb9:../../devel/libtool-base
> mktools-[0-9]*:../../pkgtools/mktools
> gmake>=3.81:../../devel/gmake
> lzip>=1.14:../../archivers/lzip
> pkgconf-[0-9]*:../../devel/pkgconf
> cwrappers>=20150314:../../pkgtools/cwrappers
> checkperms>=1.1:../../sysutils/checkperms
> dweezil# make show-depends
> libidn2>=2.3.3nb1:../../devel/libidn2
> libunistring>=1.1:../../textproc/libunistring
>
> which seems quite right to me.
> For me, pkg_rolling-replace is not at fault, it is the build-process that adds wget, at least to the wrong category.

Interesting - so we have a mismatch from the output of the three flavors
of show-depends and what is recorded, maybe.

In mk/fetch/bsd.fetch-vars.mk, the fetch tool is added to TOOL_DEPENDS,
but with a :bootstrap suffix.

If you want to dig into this, I would start tracing variable contents
and see how wget as a fetch tool ends up in USE_TOOLS, the tool
show-depends output, and the binary package.  There may well be an
inconsistency.

Things like checkperms are shown as TOOL_DEPENDS, but seem not to be
recorded.  The idea that fetch tools should be treated like that seems
reasonable.

>> I wonder about your circular dependency, what it was exactly, and if it
>> is real.  It seems like it is real, and you should perhaps exempt libpsl
>> from FETCH_USING.
>
> and libunistring.  and remove the dependency on wget from all packages
> apart from those who actually depend on it so they don’t get updated
> everytime wget gets an update.  I find that rather non-intuitive.  And
> for me, this is not a real dependency.

As I understand it build dependency changes do not cause a rebuild in
pkg_rr.  Only unsafe_depends, mismatch, or rebuild=yes.  Build
dependencies are only used in tsorting.

> RR> Tsorting dependency graph
> tsort: cycle in data
> tsort: wget
> tsort: libpsl

My impression has been that these cycles just sort of get dropped by
tsort and the tsort output ends up reasonable,  and nothing terrible
happens.  At least not bad enough that I have even started to go down
the path of fixing it.