pkgsrc-Users archive

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

Re: pkgsrc package information problem



On 8/6/23 18:29, Jan-Hinrich Fessel wrote:
Hej,

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.

That's because the package specified as FETCH_USING gets in BOOTSTRAP_DEPENDS of everything. The situation around this is rather complicated:

1. "pkg_info -N" prints @blddep lines of +CONTENTS. They are exact versions of dependencies like wget-1.21.4, not package patterns like wget>=1.21.

2. "pkg_info -n" prints @pkgdep lines of +CONTENTS. They are package patterns listed in DEPENDS.

3. @blddep is a mixture of BOOTSTRAP_DEPENDS, BUILD_DEPENDS, and DEPENDS. But it doesn't contain TOOL_DEPENDS. (why?)

4. pkg_rr, and my pkgrrxx too, wants to gather up @blddep but not @pkgdep. This is because one cannot extract a PKGBASE out of a package pattern in the general case, without consulting Makefiles, which is unacceptably slow. That is, for patterns like "wget>=1.2<3" you can conclude that the PKGBASE you're seeking for is definitely "wget". But for patterns like "{wget-[0-9]*,{xget,yget,zget}>=3}" the only way to resolve them is to run make(1). (pkgrrxx actually does this optimization in the "checking for new depends" phase, which pkg_rr doesn't.)

5. Having "digest" listed in BOOTSTRAP_DEPENDS is fine. You do need digest(1) to build a package after all, and pkg_rr should definitely rebuild digest(1) before any other packages if it's outdated.

6. Having FETCH_USING listed in BOOTSTRAP_DEPENDS is fine. Users would want to use the latest wget (or curl, or whatever) to fetch distfiles of any other packages. However, this is also problematic because it means dependencies of, say wget, depend on wget itself and create cycles.

7. pkg_rr uses tsort(1) which randomly chooses and removes arcs to break cycles. pkgrrxx doesn't use tsort(1) and aborts when it encounters a cycle. The latest version of pkgrrxx has a fragile workaround for #6: it specifically ignores @blddep entries matching FETCH_USING.

So I think #6 is the real problem. If a package is a dependency of FETCH_USING, it should be exempted from depending on it.

#3 is a side problem. I see no reason why TOOL_DEPENDS shouldn't be recorded in binary packages. It's causing a slight inconvenience for pkgrrxx because if they were recorded it could optimize some slow operations away.

Home | Main Index | Thread Index | Old Index