pkgsrc-Users archive

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

Re: topological sorting



On Wed, Jul 19, 2023 at 06:17:02PM +0200, tlaronde%polynum.com@localhost wrote:
> It seems to me that if a package depends on A, B, C, the building or
> installation tries to build A, then B, then C. It doesn't try to see if
> there are common dependencies to A, B and C and try to build the common dependencies
> first, starting by the "most" common ones? It recurses by package?

You can set up a limited bulk build using pkgtools/pbulk in a
sandbox. This will start with the packages used by most other packages
and the progress to the leaves.

> My problem---some packages are quite complex so this is not criticism: I
> know this is difficult, that there are too many variables and that the
> upstream version is not always optimal; and I'm glad I don't have to
> tackle the problem of building or installing some monsters on my own
> ;-)---so my problem is that more than once, I have been eaten by a build
> that took hours, installing a bunch of intermediary dependencies, to
> finally fail on something, meaning that a bunch of things have been
> added that are useless and tons of bytes have been downloaded that will
> be useless too since there are probably other versions that need to be
> fetched in order for the build to succeed.

The other advantage is that pbulk only provides the binary packages
for you to install later. So you can see if the packages you're
interested in built or not, and only then decide to upgrade/install
all of them/some of them (e.g. using pkgin).

> I'm trying to find a way to fail (if that has to fail) as early as possible
> and with the minimum amount of work done...

pbulk will build as much as it can before failing, so also the
dependencies that won't be needed because some other dependency
already failed.

> And, alternatively, I want to know what package has installed/required
> TeXlive (!) so this is why I wanted to know if the dependencies graph
> could be obtained by one of the tools (even if I know how to do it by
> scripting).

For pbulk, you can look at at bulklog/meta/presolve - you can parse
that to find out which package depended on which other package and
caused that to be built.

For an installed set of packages:

For run-time dependencies, 'pkg_info PKGNAME' will tell you.

FOr all kinds of dependencies, you can use the 'show-dependencies'
target, if you already have an idea what could have pulled it in.

make help topic=show-depends

For example:

devel/doxygen> make show-depends VARNAME=TOOL_DEPENDS
py311-expat-[0-9]*:../../textproc/py-expat
cmake>=0:../../devel/cmake
python311>=3.11:../../lang/python311
mktools-[0-9]*:../../pkgtools/mktools
bison>=1.0:../../devel/bison
gmake>=3.81:../../devel/gmake
gtar-base>=1.13.25:../../archivers/gtar-base
cwrappers>=20150314:../../pkgtools/cwrappers
checkperms>=1.1:../../sysutils/checkperms

Default are run-time dependencies:

devel/doxygen> make show-depends
ghostscript>=6.01:../../print/ghostscript
perl>=5.0:../../lang/perl5
graphviz>=8.0.5:../../graphics/graphviz

If you have no idea, you'll have to use grep :)
 Thomas


Home | Main Index | Thread Index | Old Index