Re: A new approach to package building

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 2 Jun 2024 19:15:51 -0500
    From:        Jason Bacon <jtocino%gmx.com@localhost>
    Message-ID:  <f1acd6ca-a924-4a04-a1c6-f6291f80106b%gmx.com@localhost>

  | 1. A correct build order.  I'm wondering if anyone has developed a tool
  | that can "sort" the pkgsrc tree, producing a linear list of
  | category/package entries where dependencies always precede their dependents.

I had that, years ago, and might still be able to find it if wanted.  Perhaps.

I used to do limited set pkgsrc builds, always one package at a time,
in a chroot - which would be populated with any required packages (and
an applicable NetBSD distribution) - the package being built would be
built to a binary package (which would be retained) and everything else
would be destroyed, and built again for the next package (using pre-built
binary packages for anything that needed to be installed).   (I also had
a fairly quick "rebuild the configured chroot" setup to speed re-init,
which was basically just a checkpoint/restore system, but that wouldn't
be interesting).

I haven't used this now for many years (perhaps close to a decade) and
it is possible that changes elsewhere might prevent it working - it simply
used pkgsrc tools to list dependancies (somehow, I forget the details, since
it was working from just pkgsrc itself, so I am guessing "make something")
into a list of tuples "package requirement" which operated recursively on
each required package, until nothing new was being added, followed by a tsort
on the result, then discarding the dependency info, leaving a list of packages
in the order they needed to be built so that (cycles excepted if any occurred)
nothing was ever needed which was not already listed to be previously built.

Then I'd simply build things in the order it said to do it (also automated).

It was geared to building a single package (and I simply repeated it for
all the packages I wanted to have existing .... and obviously even in a
sequence of such package builds, nothing was ever built twice) but I don't
think there's any reason it couldn't be extended to cover everything, that
would just result in having many, undistinguishable in this system, roots
of the various trees - ie: not all packages that act as dependencies would
end up being built before "root" packages start).

kre