Re: pkgsrc package information problem

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

PHO <pho%cielonegro.org@localhost> writes:

> 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.

It strikes me that the package should have recorded, for each
dependency:

  the pattern, and the exact package depended upon

  whether the dependency is normal, BOOTSTRAP, TOOL, Or BUILD

and pkg_info should be able to extract all of this in machine-friendly
manner.

Heuristically one can parse them in order and note when blddep is not
followed by a pkgdep that matches it and thus I think sort into real
dependencies and other types (where other is bootstrap/build and soon
tool).

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

Good question.  That feels like an oversight, but TOOL_DEPENDS is from a
different system if it is cross.  I suppose the real question is why are
BUILD_DEPENDS and BOOTSTRAP_DEPENDS listed in the first place.  Yes,
they were used in the build process, so in terms of history it means
something, but I don't really seen BUILD vs TOOL as being semantically
different: neither is needed now, and both are jus history.   One to
link with, and one to run build steps.

> 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.)

Meaning we want PKGBASE of the actual dependency.

> 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.

Yes, but this comes back to wanting to sort the build tools *that the
new build will need* before the package.  The fact that the
currently-installed package needed digest is not really important.

> 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.

Agreed; I see FETCH like I see digest.

But it is not problematic for pkg_rr as much as it actually is a
problem.  There really is a circular dependency and if one were to make
a list of PKGPATH for "keep" packages, remove all packages, and then
build them, you'd hit it.

So it is a problem in that pkg_rr of any flavor needs to break cycles to
be able to operate anywya, and to do so in the most reasonable manner.

> 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.

do you mean entries that are likely due to 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.

Do you mean one should set FETCH_USING using a conditional to exempt it?
Or something else?

> #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.

I suggest opening a new thread about TOOL_DEPENDS not being recorded
with a proposed patch.  (I am generally in favor of starting a thread
with a very descriptive sjbject and not burying that inside something
else.  And, my main computer is acting up so I am trying even harder
than usual to stay out of the critical path.)