Re: Synth status and failure to install some packages

Thomas Mueller <mueller6722_at_twc.com> wrote on
Date: Tue, 01 Jun 2021 03:49:21 +0000 :


> > synth only upgrades existing packages that are on your system, and
> > makes no assumptions about what the user wants. If you need a tool,
> > you'll have to install it - at which point it becomes a first-class
> > installed module (as opposed to those that can be auto-removed), and
> > synth will upgrade them as required.
> 
> Install using synth, or some other way?
> 

Some basic commands for installing/updating packages are:

pkg install (see man pkg-install)
pkg upgrade (see man pkg-upgrade)
pkg delete  (see man pkg-delete)

There is also an overall "man pkg". pkg does not
care if poudriere vs. something else created the
repository(s) it gets packages from. The path
to the repository used might indicate what software
manages the repository, such as poudriere.

An example if indicating to pkg to use a local
repository instead of the remote FreeBSD one is:

# find /usr/local/etc/pkg/repos/ -print
/usr/local/etc/pkg/repos/
/usr/local/etc/pkg/repos/FreeBSD.conf
/usr/local/etc/pkg/repos/custom.conf

# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD: { enabled: no }

# cat /usr/local/etc/pkg/repos/custom.conf
custom: {
        url: "file:///usr/local/poudriere/data/packages/13_0R-CA72-default",
        enabled: yes,
}

So in this case I have configured pkg to use a
repository that poudriere happens to maintain.

"pkg install" will install run-depencencies.
It will not automatically install
non-run-depenendecies, such as
build-dependencies. But they can be installed.
This is not a poudriere definition, but a pkg
definition.

"pkg update" will install newer versions of already
installed packages if the respository is more
update for those packages than before.

"pkg delete" uninstalls packages, including packages
that have a run-dependency on what is being deleted.

I'll note that poudriere updating of the repository
involves using packages from the repository in a
sort of virtual environment (a jail). During this
the required build packages are temporarily installed
as needed in the virtual environment. There is no need
to have the build dependencies installed at the
FreeBSD system level for these builds to happen. A
desire to do other forms of building could lead to
deciding to install some build dependencies into
the FreeBSD system (outside the virtual environment).

For poudriere, merely rebuilding does not update what
is installed in the live overall system. pkg is used
for that --after a build completes.

> > This is useful for some of my systems where I don't need the
> > build-tools, only the end-result package.
> 
> > Cheers.
> 
> > Jonathan Chen <jonc_at_chen.org.nz>
> 
> I would likely want to build the packages on a different partition so as to keep my present outdated installation intact and not lose everything if rebuilding messes up.
> 
> This new partition now has an old 13-current or 12-stable from May 2019, internet connectivity not functional, which I would upgrade to 14-current, or less likely, 13-stable.
> 
> If the upgrade build fails, or if internet connectivity is still nonfunctional, then back to NetBSD.
> 
> I could use pkg query (is that it?) to make a list of all installed packages and use that with synth, but have had instances of packages named on the synth command line building but not installing.
> 
> One nice feature of package management systems is pulling in dependencies without having to name every package explicitly.
> 
> Does poudriere also fail to install build dependencies?  I never used poudriere.

See my notes above where I try to give a quick description.

Other than an experiment years ago, I've not used synth
because I also build on/for platforms that synth did
not support and I want to use the same toolchain structure
across all the platforms.

In my context, there are lots of build-dependencies that
I've no use for in the overall FreeBSD environment. I do
explicitly install a few that I use separately from
building packages out of ports, some llvm* and gcc*
compiler related toolchain packages are examples. But,
for example, there are other programming languages used
in building some ports that I make no other use of.
poudriere deals with using them as needed during
repository updates without them needing to be installed
in my overall system.

An example of finding run vs. build dependencies is:
(presumes options are already established)

# cd /usr/ports/lang/gcc10
# make run-depends-list | sort
/usr/ports/devel/binutils
/usr/ports/math/gmp
/usr/ports/math/mpc
/usr/ports/math/mpfr
/usr/ports/print/indexinfo

By contrast build-depends are below.
Some ports show up in both lists.

# make build-depends-list | sort
/usr/ports/converters/libiconv
/usr/ports/devel/binutils
/usr/ports/devel/gmake
/usr/ports/lang/perl5.32
/usr/ports/math/gmp
/usr/ports/math/mpc
/usr/ports/math/mpfr
/usr/ports/ports-mgmt/pkg
/usr/ports/print/texinfo

So the following are not required to
use gcc10 as I have things configured:

/usr/ports/converters/libiconv
/usr/ports/devel/gmake
/usr/ports/ports-mgmt/pkg
/usr/ports/print/texinfo

But they were used during the build of
gcc10.

Turns out other things require libiconv as
a run-dependency and pkg is nearly always
installed in the overall system. But, in my
context, gmake and texinfo are not installed
in the overall system: the use is internal
to poudriere's build activity only.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)