Re: gimp 3.0

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

On Tue, Apr 08, 2025 at 06:35:50PM +0100, Jonathan Perkin wrote:
> * On 2025-04-08 at 13:35 BST, Adam wrote:
> 
> > Now that graphics/gimp-devel is at 3.0.2, are we ready to update graphics/gimp to 3.0.2 and remove the former?
> > Any objections?
> 
> FWIW you changed the gimp-devel PKGNAME, and now:
> 
>   pbulk-resolve: No match found for dependency gimp-devel>=2.99.10 of package gmic-3.2.3nb25
>   pbulk-resolve: No match found for dependency gimp-devel>=3.0.0rc1nb4 of package gmic-3.2.3nb25

I changed it back.

> I'm not sure if anyone cares about this any more, as my pbulk is still
> running a version prior to the ignore_missing_dependencies removal, but
> something to consider.

There is no connection between the change in pbulk and caring about
this or not. I care about this, but I also care about bulk builds
starting and providing results.

I feel we had this discussion a couple of times already, but we don't
understand each other, so it's never resolved.

I'll try summarizing my side again, perhaps you can do the same and we
can check where we really disagree.

1. The problem we're talking about is when a package dependency is
   broken, for example when

   a) DEPENDS+=foo-[0-9]*:../../devel/bar (wrong path)

   b) DEPENDS+=foo-[0-9]*:../../devel/foo but foo contains Foo or some
   other variation

   c) DEPENDS+=foo>=2:../../devel/foo but foo contains an older version

   d) DEPENDS+=${PYPKGPREFIX}-foo-[0-9]*:../../devel/py-foo but the
   package does not support a Python version that the package using it
   wants

2. When running a bulk build when pkgsrc is in this state, we had/have
   the following behaviours:

   a) not start the bulk build at all (default behaviour up to January
   2025, removed), writing an error on the pbulk console which only
   the person starting the bulk build sees.

   b) when a setting (ignore_missing_dependencies) is set, start the
   bulk build but have weird errors in the installing-depends-step (I
   think) of the log, which are at least uploaded with the results and
   everyone can see them, and we have binary packages for all packages
   that are not affected (optional behaviour up to January 2025,
   removed); debugging this problem needs knowledge about this
   particular error case.

   c) get an explicit error about the broken dependency for the
   package, a separate section where all packages failing for this
   reason are listed, and binary packages for all packages that are
   not affected (default behaviour after January 2025); the problems
   are still listed on the console, so if the bulk build admin was
   watching that before for such problems, they can still do that

3. From these three cases, I prefer c) because

   a) we have binary packages for all packages that are not affected

   b) we have an easily visible overview about which packages have
   dependency problems in the summary, and a clear error for each such
   package

   c) not only the person starting the bulk build is informed by
   default, but it's published as part of a standard bulk build upload
   by default, so the list of people that are notified and can fix it
   is increased.

Please let me know where you have a different view.

Thanks,
 Thomas