Re: Unannounced commits

[Jason Bacon <jtocino%gmx.com@localhost>]

On 12/29/22 07:36, Benny Siegert wrote:
> Hey Jason,
>
> On Tue, Dec 27, 2022 at 8:54 PM Jason Bacon <jtocino%gmx.com@localhost> wrote:
> > In addition, biology/bcftools was *not* upgraded along with them and is
> > now out of sync with htslib in the quarterly packages.
> >
> > https://github.com/samtools/bcftools/releases/tag/1.16
> >
> > biology/kallisto also depends on htslib.  I see no discussion about this
> > on the mailing lists, and I had no opportunity to test the v1.16
> > packages before they were committed, or retest kallisto with htslib 1.16.
>
> Having to consult with the maintainer before each update doesn't
> scale. How about this: put all the things to keep in mind when
> updating into a comment in the Makefile. This could be things like
> "keep this other package in sync", "verify that this other package
> still builds", etc. This way, whoever does the update can verify these
> themselves.

What you're suggesting for the comment should be standard procedure for 
all package updates, assuming we want software installed via pkgsrc to 
work reliably.

Specifically, before any package is updated, I think the following 
should always be done:

1. Identify all dependent packages.  For anything with a bl3, like htslib:

NetBSD netbsd9.acadix  bacon ~ 1015: (pkgsrc): find ~/Pkgsrc/pkgsrc/ 
-mindepth 3 -maxdepth 3 -name Makefile | fgrep -v wip/ | xargs grep -l 
'include.*htslib'
/home/bacon/Pkgsrc/pkgsrc/biology/bcftools/Makefile
/home/bacon/Pkgsrc/pkgsrc/biology/kallisto/Makefile
/home/bacon/Pkgsrc/pkgsrc/biology/samtools/Makefile

For non-libraries, replace 'include.*' with 'DEPEND.*'.

2. Upgrade interdependent package together wherever possible and 
appropriate.

3. Check upstream change logs for any API changes.  Don't expect 
reliable information, if any, but it might save time by revealing 
potential issues.

https://github.com/samtools/htslib/releases/tag/1.16

4. Build test all dependent packages with the new dependency.

5. Run test any dependent packages that might possibly be affected by 
the change, whether or not any API changes were published.  API-related 
breakage happens all the time.  I had problems with htslib/kallisto in 
the past.  Just hit one with coreterminal/qtermwidget in FreeBSD ports, 
where no API changes were indicated, but a new package build was necessary.

5. Resolve all build or run problems before committing anything.

6. Don't commit untested upgrades shortly before a branch.  If both 
quarterly and latest packages are broken, pkgsrc simply won't be an 
option for deploying that software.

Contacting the maintainer, who is presumably familiar with the software, 
is much easier than verifying all this on your own if you're not a user.

Since we have a system in place for addressing this, though I don't 
think it's a very good one, I will use it.  I've already updated my 
critical packages and my $0.02 is on record.  Assuming people respect 
OWNER=, I will leave this debate to others from here on.