tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Unannounced commits

On 12/29/22 07:36, Benny Siegert wrote:
Hey Jason,

On Tue, Dec 27, 2022 at 8:54 PM Jason Bacon <> wrote:
In addition, biology/bcftools was *not* upgraded along with them and is
now out of sync with htslib in the quarterly packages.

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

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'

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.

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.

Home | Main Index | Thread Index | Old Index