Re: either/or dependencies breaks show-depends-pkgpaths?

[Richard Hansen <rhansen%bbn.com@localhost>]

On 2014-01-18 01:41, David Holland wrote:
> On Fri, Jan 17, 2014 at 07:28:18PM -0500, Richard Hansen wrote:
>>> 7. If the package depends on either one of two (or more) packages,
>>>    specify the ?pre-req-package-name? as a comma-separated list between
>>>    curly braces.
>>> 
>>>    As an example, take a package that depends on the Perl "version"
>>>    module, which has been part of Perl itself since version 5.10.0. This
>>>    either/or dependency is expressed as:
>>> 
>>>        DEPENDS+= {perl>=5.10.0,p5-version-[0-9]*}:../../devel/p5-version 
>> 
>> The 'show-depends-pkgpaths' target appears to break on these either/or
>> dependencies:
>> [snip]
> 
> I think it's negotiable whether that's actually broken,

I consider it to be broken because the behavior differs from what is
expected and relied upon by users of pkgsrc (namely me :) ) and pkgsrc
itself.  It affects depends-depth-first.awk, which in turn affects the
following make targets:

  * clean-depends
  * build-depends-list
  * depends-checksum
  * fetch-list-recursive
  * depends-fetch
  * show-depends-options
  * show-needs-update

plus all targets that depend on or execute the above targets, directly
or indirectly.

> but it
> certainly isn't helpful if you're trying to use the output to plan or
> control builds.

Unfortunately that's precisely what I'm trying to do.  :)

> 
> One possible way to fix it would be to move it to where it can depend
> on the package tools and make it work like show-installed-depends;
> that isn't necessarily what one wants though (as the answers will
> depend on what's installed)...

Right -- I need it to not depend on what's installed.

I use show-depends-pkgpaths to generate lists of packages that must be
built to upgrade to a new quarterly branch.  I generate these lists
before building anything.

In particular, I use the output of show-depends-pkgpaths to determine if
a package dependency's version has changed with the new quarterly
branch.  If so, I rebuild the package even if the version of the package
itself did not change with the new quarterly branch.  (I do this just in
case there is an ABI change in the dependency.)  With the current
behavior of show-depends-pkgpaths I get false positives -- the packages
listed in pkg_info -N don't match the packages listed by
show-depends-pkgpaths so a rebuild is always performed.

> another is to pass it through something
> like reduce-depends.awk, but of course it isn't entirely trivial to do
> this reduction. (AFAICT reduce-depends.awk currently doesn't handle
> it.) (Also, while this will cover Perl modules it won't work in
> general.)

reduce-depends.awk uses pkg_admin to resolve the dependency, and
pkg_admin queries the set of installed packages.  So this also doesn't
work for me.

A couple of other approaches, neither of which is a trivial change (I
think):

  * alter/extend the DEPENDS syntax to include the pkgpaths of all of
    the options in an either/or dependency:

        perldep=     perl>=5.10.0
        perldir=     ../../lang/perl5
        p5verdep=    p5-version-[0-9]*
        p5verdir=    ../../devel/p5-version
        DEPENDS+=    {${perldep}:${perldir},${p5verdep}:${p5verdir}}
     or:
        DEPENDS+=    {${perldep},${p5verdep}}:{${perldir},${p5verdir}}
     or:
        DEPENDS+=    {${perldep},${p5verdep}}:${perldir}:${p5verdir}

  * walk the entire pkgsrc tree and generate a mapping from pkgname to
    pkgpath, then use that mapping to figure out where to go to find any
    of the options in the either/or dependency

With either of the above changes, show-depends-pkgpaths would be altered
to print:

    {lang/perl5,devel/p5-version}

instead of a single pkgpath.

Then the question arises as to how depends-depth-first.awk would choose
a pkgpath when resolving an either/or dependency.  In general, the
"best" option might depend on factors that are outside pkgsrc's
knowledge, e.g, if the user will be installing one of the options anyway
because it is a dependency of a different package.

One possible algorithm is to choose the first match from the following list:

  * an explicit preference specified in /etc/mk.conf
  * the first in the list of options in the either/or dependency

I'm tempted to insert the following between the above two, but I'm not a
fan of dependency resolution relying on information outside the pkgsrc tree:

  * the pkgpath of the package returned by pkg_info -E

Unfortunately I don't foresee having the time to implement something
like the above, so I think I'll either have to live with the bug or
figure out a workaround.

Thank you for your help,
Richard