Re: Package naming when no backward compatibility at all?

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 10/19, Greg Troxel wrote:
> The rule is to increase PKGREVISION of all depending packages if (and
> only if) there *is* an ABI break.   Sometimes that is "there seems like
> there might, so err on the side of caution", which leads to unnecessary
> rebuilds.
> 
> An ABI break can be any of:
>   - symbol withdrawn in a shlib
>   - calling args changed in a function in a shlib
>   - behavior changed for any function, other than bug fixes
>   - any program/script which could reasonably be used by another program
>     changing behavior (in a non-bugfix way)
> 
> Whether or not ABI changes happen in various kinds of releases is an
> upstream ASE issue, and is not relevant to the revbump process.
 
OK, I think the difficulty is that upstream does not make this clear,
and it's not always easy to tell.  I was leaning toward doing a
preemptive revbump since I know upstream's policy, but it sounds like
you think that's not a good idea.  You think that I should assume that
there's no API/ABI break, and I should only do a revbump if I know there
has been a break.  Am I understanding correctly?

> > In package foo's buildlink3.mk file, I think I'd use "=" for the
> > BUILDLINK_A{P,B}I_DEPENDS.foo assignment, not "+=", and set an exact
> > match for the dependency, not a package wild card.  For example, I think
> > I'd want to use
> >
> >   BUILDLINK_API_DEPENDS.foo=     foo-7.0.9
> >   BUILDLINK_ABI_DEPENDS.foo=     foo-7.0.9
> >
> > not
> >
> >   BUILDLINK_API_DEPENDS.foo+=    foo>=7.0.9
> >   BUILDLINK_ABI_DEPENDS.foo+=    foo>=7.0.9
> >
> > This way, I'd catch at build time any API changes, and I think this
> > would make a binary package upgrade work too.
> 
> This is contrary to pkgsrc norms.

OK, then if you think it would be better to assume no API/ABI break, and
only change the API/ABI depends when I know there's a break, I could do
it that way.  My biggest concern, though, is that I probably won't know
if there's a break because I won't be able to test all of it.  So, that
makes me nervous that the packages will be broken more often than not.
If I were to do the revbump and change the API/ABI depends for every
release, I was thinking that I would have a better chance of inverting
that so that the packages would likely be working more often than not.
 
> You haven't yet explained whether *every single* release from this
> upstream has an ABI break, or what fraction of them.

Probably not every single release, but it could be.  I didn't explain
what fraction have an API/ABI break because I don't know, and I don't
think upstream knows either.

> (You haven't named it either, so nobody else could look.)

I think it would not be easy to find out, so I didn't think it would be
useful to name it.  But anyway, it's EPICS and the various modules and
extensions for it:

* https://epics-controls.org/
* https://epics.anl.gov/

Here's a link into a related mailing list thread (which also points to
another thread) on upstream's backward compatibility stance:

* https://epics.anl.gov/core-talk/2021/msg00523.php

Thanks,

Lewis