On 2/20/24 06:13, Jamie Landeg-Jones wrote:
Mark Millard <mark...@yahoo.com> wrote:
It probably should be separate from this topic, but I'd interested
to understand some example types of changes folks make for which
poudriere prevents the changes from working but for which portmaster
use or make use allows the change to work.
I've many changes, nothing that would upset poudriere though.
I've probably grasped the wrong ideas from this thread. I thought it was
about the implied effective deprecation of the ports infrastructure for
a binary package only structure, with poudriere being used to create
custom packages in any way it wants going forward.
If pordriere continues to build via the make system we have already,
then I can't see any issue.
What's the reasoning behind people claiming a shift from "make install"
to poudriere is necessary?
I don't consider it necessary, but building in a clean environment is
desirable to minimize issues and maximize uptime. Some ports will fail
to build or install when certain other packages have been installed;
proper solution is to open a PR to get such cases identified and
resolved. I'd go as far as to say a port should be marked as
incompatible with itself if it uses already installed tools from an
older version of the port or from a non-dependent package in place of
ones that were built in the port's work directory as I have had builds
fail doing an x86-x64 rebuild+reinstall step without first removing them
(likely to be unsupported) and when trying to perform a general upgrade
of an installed package/port (should be supported). Fixing the port's
build system would be much more desirable to marking it as incompatible
with itself but if a condition is detected where builds can go wrong
then it is better to mark it as broken than let the user fail trying.
In the past, I have reported such breakages and even when pkg-plist
needed to be conditionally altered if something was already installed
and maintainers addressed the issues accordingly. Dynamic dependency
testing that a port's build system does should be changed to be manually
fed a list of dependencies based on port options or the dependencies can
be unconditionally added to avoid surprises that people get building a
port on a clean machine vs one with an optional dependency already
installed; it isn't 'necessary' but creates better conditions for
packages to always match what a user could get and gives everyone less
surprises.
I have had other issues in the past by old remaining files from bad
pkg-plist leaving things behind, unclean work directories (I hope this
is not why the workdir is currently a version dependent folder; that
practice needs to stop to greatly improve ccache results), and
dependencies getting out of sync if port versions were not properly
recursively bumped.
When it comes to upgrades, a clean build environment is superior.
Software often won't work when an upgrade has been partially performed
which can break on the first run/lib dependency and isn't usable until
the port itself is rebuilt after. That leads to a downtime of hours to
days depending on how much work the machine has to do to do an update.
If the upgrade fails partway through, software may continue to be
unavailable until a port is fixed or downgraded to a previously unbroken
version if no older package was saved to reinstall. Recursive dependency
version bumping has had issues.
As for my use, I'm a desktop user currently on older hardware and
have felt my own pain learning how to try to use poudriere with it.
Wonder if thigns have changed because 13-stable feels more painful than
I remember when CPU gets heavily loaded by idprio'd processes.
Poudriere's defaults are not sane for a modern desktop user but I do not
have a 'good' non-manual fix until we start recording various build
requirement details into ports themselves (which is an idea needing its
own topic).
Cheers, Jamie
