On 2024/11/23 15:21, Edd Barrett wrote:
> Hey Stuart, Jeremie,
> 
> Thanks for the input/comments on this. Sorry I haven't had time to chime in
> until now.
> 
> The extra bin/ entries are easily fixed. No problem there.
> 
> On Fri, Nov 22, 2024 at 07:16:14PM +0100, Jeremie Courreges-Anglas wrote:
> > On Fri, Nov 22, 2024 at 05:23:32PM +0000, Stuart Henderson wrote:
> > > > > Also I'm not 100% sure but I think the "updating" of @conflict markers
> 
> About these conflict markers. It was my understanding that they are the way
> they are for two similar, but related, reasons:
> 
>  - a) to prevent texmf subsets from different texlive years from being
>       installed simultaneously, especially during updates. e.g. you can't mix
>       texmf packages from TL23 and TL24. Files could conflict due to upstream
>       tex package dependency changes between different versions of tex live.

It's not really possible to support partial updates of packages,
anything other than pkg_add -u against a synced-up mirror is likely to
result in some breakage, I don't think it's the job of @conflict (which
is just meant to record packages where files are actually conflicting)
to enforce that.

>  - b) for when files are moved from one OpenBSD texmf package to another, by
>       us. This typically happens when someone asks to put another tex package
>       into the buildset. Without strict conflict markers, i.e. with a specific
>       REVISION, the update doesn't work. That's caught me out in the past.

That is what @conflict is for, but I think it should only be used for
"actually conflicts" and not "theoretically might conflict but we didn't
check".

If these packages weren't so huge it wouldn't be such a problem, but
there's a lot of disk space pressure when they're updated, so there's a
good reason to keep the update sets as small as possible.

> (There's a comment in texmf/Makefile that discusses the latter)

Changing every @conflict line goes beyond what that comment describes.