Re: policy proposal: updating packages with many dependencies

[Thomas Klausner <wiz%NetBSD.org@localhost>]

Hi!

Thank you for the feedback.

I think I'd like to concentrate (for now) on making pkgsrc more stable
by handling packages that have caused trouble before with more care.

The 'abi' point matches, I think, what I proposed - packages that have
caused problems before because of ABI (or API) changes.

I can get behind the 'bootstrap' list, but we need to come up with a
workable procedures for when updates to these packages can be
committed. Requiring a full bulk build doesn't sound reasonable; on
the other hand, having 'bootstrap' finish a couple of platforms sounds
like too little.  I'm not sure where the golden middle for this
is. Perhaps building meta-pkgs/bulk-test-essential?

But we need some infrastructure to test this, I don't think it's
realistic to assume that committers can test on even 3+ platforms. If
you could provide infrastructure for this, that would be appreciated.

'portability' is a new one for me. Do you have some more examples of
such packages? I wasn't even aware that ghostscript was problematic in
this respect. Do we enough of these that they should be part of this
now?

IMHO, 'lts' does not fit here. I think the proper solution for this is
having foo and foo-lts packages, like the ESR packages we have for
firefox; perhaps with some kind of lts.mk files that globally switch
to the lts or the HEAD version, if other packages depend on them.

I'm not convinced of the 'quarterly' category yet and would like to
discuss that at some other time, if that's ok.

So for now I'd go with

POLICY_UPDATE_LIMITED=  abi

and add 'bootstrap' and 'portability' once we have a more detailed
procedure for updating them.

I've drafted an update for the pkgsrc guide, see attachment.

Cheers,
 Thomas

Index: files/Makefile
===================================================================
RCS file: /cvsroot/pkgsrc/doc/guide/files/Makefile,v
retrieving revision 1.22
diff -u -r1.22 Makefile
--- files/Makefile	1 Oct 2021 17:20:27 -0000	1.22
+++ files/Makefile	27 Mar 2025 21:40:01 -0000
@@ -35,6 +35,7 @@
 SRCS+=	pkginstall.xml
 SRCS+=	platforms.xml
 SRCS+=	plist.xml
+SRCS+=	policies.xml
 SRCS+=	porting.xml
 SRCS+=	regression.xml
 SRCS+=	submit.xml
Index: files/chapters.ent
===================================================================
RCS file: /cvsroot/pkgsrc/doc/guide/files/chapters.ent,v
retrieving revision 1.20
diff -u -r1.20 chapters.ent
--- files/chapters.ent	1 Oct 2021 17:20:27 -0000	1.20
+++ files/chapters.ent	27 Mar 2025 21:40:01 -0000
@@ -33,6 +33,7 @@
 <!ENTITY chap.submit			SYSTEM "submit.xml">
 <!ENTITY chap.devfaq			SYSTEM "devfaq.xml">
 <!ENTITY chap.gnome			SYSTEM "gnome.xml">
+<!ENTITY chap.policies			SYSTEM "policies.xml">
 
 <!-- The pkgsrc infrastructure -->
 <!ENTITY chap.infr.design		SYSTEM "infr.design.xml">
Index: files/pkgsrc.xml
===================================================================
RCS file: /cvsroot/pkgsrc/doc/guide/files/pkgsrc.xml,v
retrieving revision 1.44
diff -u -r1.44 pkgsrc.xml
--- files/pkgsrc.xml	1 Jan 2025 01:39:11 -0000	1.44
+++ files/pkgsrc.xml	27 Mar 2025 21:40:01 -0000
@@ -98,6 +98,7 @@
     &chap.fixes;
     &chap.gnome;
     &chap.submit;
+    &chap.policies;
     &chap.devfaq;
   </part>
 
Index: files/policies.xml
===================================================================
RCS file: files/policies.xml
diff -N files/policies.xml
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ files/policies.xml	27 Mar 2025 21:40:01 -0000
@@ -0,0 +1,53 @@
+<!-- $NetBSD: submit.xml,v 1.42 2024/10/11 20:21:27 jkoshy Exp $ -->
+
+<chapter id="policies"> <?dbhtml filename="policies.html"?>
+<title>pkgsrc Policies</title>
+
+<sect1 id="stability">
+<title>Packages for which updating is restricted</title>
+
+<para>In the past, some packages have caused more package failures than others, and we'd like to reduce this in the future.</para>
+
+<para>For this reason, we mark some packages with <varname>POLICY_UPDATE_LIMITED</varname>. The possible values currently are:
+<itemizedlist>
+  <listitem><para><literal>abi</literal> for packages where ABI/API changes often broke the packages depending on them </para></listitem>
+<!--  <listitem><para><literal>bootstrap</literal> for packages that are used during the pkgsrc bootstrap</para></listitem> -->
+</itemizedlist>
+<filename>pkglint</filename> will warn when committing updates to these packages.</para>
+
+<sect2 id="stability.abi">
+  <title>Limited Updates - ABI</title>
+
+<para>Before committing non-micro version updates to any of the following
+packages:
+<itemizedlist>
+  <listitem><para><filename role="pkg">devel/boost*</filename></para></listitem>
+  <listitem><para><filename role="pkg">lang/erlang</filename></para></listitem>
+  <listitem><para><filename role="pkg">textproc/icu</filename></para></listitem>
+  <listitem><para><filename role="pkg">lang/llvm</filename></para></listitem>
+  <listitem><para><filename role="pkg">print/poppler</filename></para></listitem>
+  <listitem><para><filename role="pkg">lang/rust</filename></para></listitem>
+</itemizedlist>
+</para>
+<para>a limited bulk build of <filename
+role="pkg">meta-pkgs/bulk-test-${PACKAGE}</filename> needs to be run
+and the result posted to the tech-pkg mailing list, highlighting what
+packages would stop building (if any).</para>
+
+<para>Depending on the result, pkgsrc-pmc then decides:
+<itemizedlist>
+  <listitem><para>go ahead with the update</para></listitem>
+  <listitem><para>wait for packages X, Y, Z to be fixed (upstream or locally) with the
+  updated version, which is put in wip in the meantime</para></listitem>
+  <listitem><para>In the second case, all pkgsrc developers are encouraged to work on
+  fixing this - it is not only the updater's task to fix them.</para></listitem>
+</itemizedlist>
+</para>
+
+<para>The decision to wait for packages can be revisited.</para>
+
+</sect2>
+
+</sect1>
+
+</chapter>