Re: Package naming when no backward compatibility at all?

[Greg Troxel <gdt%lexort.com@localhost>]

"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:

> 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?

More or less, yes.

Again my question is: how do other packaging systems deal with this?
how does anybody else?

> 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

No, but if you can rebuild everything that depends on it, and it builds
ok, things are likely ok.

> makes me nervous that the packages will be broken more often than not.

Are they really changing behavior in a way that the other programs build
but fail to run?

> 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.

To me that seems unreasonable.  I don't know what others think - I am
just one.

> 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.

wow, but it is how it is.

> 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

So they are trying to avoid API breaks that are messy.

For ABI, are they changing the shlib major version number on breaks like
ELF requires?

I really don't know what to say; I've never seen an upstream this far
off into space.