Re: topological sorting

[tlaronde%polynum.com@localhost]

Le Wed, Jul 19, 2023 at 08:57:47PM +0200, Thomas Klausner a écrit :
> 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).

OK, thanks for the tip. It seems that pbulk is indeed what I'm looking
for: trying to build without rendering present working (if not up to
date) installation.

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

I found (I didn't know about it) that:

$ pkg_info -r "tex-texlive*"

will give me, recursively, the packages depending on this.

In this case I found that texlive has been pulled in by an indirect
dependency on gl2ps, needed by vtk, needed by pcl, needed by pdal-lib!

So please don't feel offended: I'm quite satisfied to have pdal working
without much ado :-) (French IGN has switched to this format for LIDAR
open data, so I will be able to use them without using Windows).

But I hope that some day developers (vtk) will realize that they
have to stop bringing in dependencies of such size (gl2ps is small;
but its dependencies are huge!).

Best,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C