pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkgsrc package information problem



Jan-Hinrich Fessel <oskar%fessel.org@localhost> writes:

> while sorting out some other bugs in som software, PHO and i ran across a circular dependency in some of my systems.
> I found out  that in the package information there is too much information stored.
> Example:
>
> dweezil# pkg_info -rN libpsl
> Information for libpsl-0.21.2:
>
> Built using:
> libidn2-2.3.4
> libunistring-1.1
> digest-20220214
> wget-1.21.3nb2
>
> Full required by list:
> wget-1.21.4
>
> This is completely wrong from my point of view.  A package should
> never have the „FETCH_USING“ part recorded as being built with,
> because it has no impact on the actual build process and implies it
> can only be rebuilt using that circular dependency.
> Probably noone else uses pkg_rolling-replace in combination with FETCH_USING.  But this looks like a design error to me.

Perhaps this is a side effect that FETCH_USING adds a BUILD_DEPENDS
(which is maybe TOOL_DEPENDS or should be).

It seems ok to record this as a dependency that *was used to build the
package*.  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)

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.

> Side Note: i happen to be forced to use wget (or curl) to get the
> sources from some sites, because the connection to my build servers
> somehow prevents netbsd’s ftp to successfully retrieve them (github,
> pythonhosted,…).
> That is a bug in the provider connection that wget can somehow mitigate most of the time...

As Joseph taught Eliza to say, many others have the same sorts of
problems.

I have worked around this by

  route add -inet6 2a04:4e42:1c::/32 [my LAN router's IPv6 addr] -reject

However, I never added it to boot config, and have rebooted machines and
not noticed problems.  So maybe I'm just not fetching, or maybe it is
fixed.


Home | Main Index | Thread Index | Old Index