> On Sep 25, 2023, at 18:23, Roger Marquis wrote:
>
> On Mon, 25 Sep 2023, Mark Millard wrote:
>> ... it takes so long to build (and distribute) the 30,000+
>> packages (or any large incremental subset or subset that
>> involves huge builds) that a fair number ports have had
>> updates before the distribution completes and starts being
>
> Even just getting the ports tree updated can take days (or more) even
> after vulnerabilities are patched.
Let's assume for most systems, you're dealing with a quarterly ports tree, and
thus a quarterly pkg tree. If you're using a -current ports tree, all bets are
off, but portsnap (in base) should qualify you for this.
> Take bind9 for example. We use Poudriere for most updates but not bind9
> as it often should be patched as soon as updates are are available. If
> you wait for gitup or Poudriere to pull a new Makefile, even with
> nothing more than a new version string, it can take days (2 or 3 days
> for the most recent patch). It's not an issue here as we a) edit the
> Makefile to specify the current version, b) make makesum, c) make sure
> the build does not use python (by manually editing the port's options
> file, d) make package and e) pkg install (or update), which takes
> maybe 10 minutes.
This was my precise reason for setting up poudriere to keep building a constant
set of quarterly builds -- even if we don't use them at all. By default, we
stick with the base packages, but we want to be able to mode-switch over, in
the event we have a critical patch we need to apply.
-Dan
> It sounds like what we really need om this case is just a way to
> maintain options keys and values that are not specified in the Makefile.
> Of course that won't work for all bloated packages but it would help.
>
> Roger Marquis
