Maybe I don't understand this correctly, but I don't understand how this would help you.

Either there are packages which link against gpsd and rely on its API / ABI (in which case they would be broken by this change), or there aren't any such packages (in which case you could just update the package even if it broke ABI, since it would have no effect).

Or are you proposing to maintain two packages for gpsd, one that keeps its ABI stable and which applications can link to, and another one without public API that can have "breaking" changes?

Yes, two gpsd packages, with a conflict between them. One provides the library for other packages, but cannot be updated easily due to the API/ABI breaks. The other one has the library only for its own use, so it can be updated easily.

If the two resulting packages conflict with each other, I don't think this is a good solution. Wouldn't this essentially make using gpsd daemon and gpsd API on the same system imposssible?

So in general I think the packager must be free to decide what they want to include in their packages, assuming of course that they take care not to break other parts of the distribution.

However, two (or more) packages which conflict (at the RPM level) seems to me to be a poor solution, because this partitions the set of packages which might depend on gpsd into those which need one variant and those that need another, with users being forced to choose. But even if you had parallel-installable packages, I imagine you still wouldn't be able to run two different daemons at the same time, so I'm not sure if that would save you.

I guess I just don't understand enough about gpsd to know what possible solutions would work. It doesn't look like much in the distribution depends on it, but that doesn't mean that someone wouldn't install it and then build something against it.

And finally, some things just aren't suited to EPEL. If a piece of software is so poorly engineered that it can't maintain any form of stability on updates then it probably just shouldn't be packaged there. 13 months of Fedora can be tough enough.

My suggestion is that if you need to update this in an incompatible way within either a Fedora or EPEL release, then each time you do it you create a compatibility package providing the previous C library and development files. The Python library and CLI tools probably should only exist within the leading unversioned package. This would allow updates to the CLI tools without disturbing packages that link against the C library. The compat -libs package would be parallel installable so that packages built against the old C library can be installed at the same time as packages built against the new C library. The compat -devel package would conflict with main -devel package.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_compat_package_conflicts

This could start with an update that simultaneously introduces gpsd3.23 and upgrades gpsd from 3.23 to 3.25. Future incompatible upgrades could follow the same pattern. An update of gpsd from 3.25 to 3.26 would need to add a gpsd3.25 compat package. An update of gpsd from 3.26 to 3.27 would need to add a gpsd3.26 compat package. While I understand that maintaining multiple compatibility packages is not appealing, it's what is required to follow update policies. The alternative is to only make the incompatible changes in Rawhide, and leave the version alone in stable Fedora and EPEL branches.

Rebasing and adding only compat -libs and -devel packages for the old version could break existing applications of the C library and also python applications using the gps module. It doesn't look like older versions of libgps are expected to interoperate with newer gpsd. The applications from the -clients package complain about API mismatch and at least the cgps application from EPEL8 doesn't seem to work with the latest gpsd. The original gpsd and python modules should be kept for compatibility.

The recommended approach adding a conflicting fully-featured gpsdX.XX package for each new release would lead to a larger number of packages and the problem with different packages depending on different gpsd versions, possibly preventing installation of some unrelated packages due to the conflict.

With the intended use case in EPEL, I think it's best for the new package to simply not provide the library and python module for other packages.

Can you please confirm the policy allows adding a second package of the same thing with a different set of features? Would any of gpsd-newer, gpsd-later, gpsd-nolibs, gpsd-minimal be an acceptable name?

For reference, here is the proposed spec of the package:
https://fedorapeople.org/~mlichvar/tmp/gpsd-latest.spec

Here is the diff of the files section against the original package:
https://fedorapeople.org/~mlichvar/tmp/gpsd-latest.files.diff.txt

Some other possible names of the package that came to my mind: gpsd-noapi, gpsd-timeserver

We sympathize but it's going to be very difficult to have anything that works as well for everybody as the obvious:

1. Have an "oldish"/stable version in EPEL.
2. Have a latest version in COPR, which breaks library API.
3. Occasionally update the oldish version with the EPEL process for incompatible updates.

Ok, ticket is closed, but I still don't have an aswer to my questions.

If modularity was still a thing, this would be a use case for it. Basically, I'm trying to add a second stream of gpsd to EPEL, but avoiding the issues that modularity had by not providing a library.

If you don't mind me asking again, is there any policy that prevents me from implementing my solution?

I think I said my piece previously, but I'll elaborate just to add something since there are still questions. The guidelines here are designed to prevent poor user experience where unrelated leaf packages can't be installed together due to weird conflicts down in their dependency trees. So what is the user experience going to be here?

Fundamentally (and from a Fedora perspective): Don't bifurcate the package set into those which require one gpsd version and those which require another.

I would even say that it would be just barely acceptable to have everything in Fedora require one version, while keeping an old version around on which nothing depends for the purpose of not breaking self-compiled code. An that's accepting that having that old version installed prevents installation of any package in the distribution which uses gpsd. But existing policy around updating that "-unstable" or whatever version would need to be followed, along with all of the coordination required to update everything that uses it together. And EPEL update policy is going to be quite a bit stricter than Fedora's, so that solution would probably not be workable there and you would have to ask the relevant committee about that.

Fundamentally (and from a Fedora perspective): Don't bifurcate the package set into those which require one gpsd version and those which require another.

That's exactly what I tried to do with the gpsd-minimal package. It doesn't contain any libraries on which other packages could depend on. The two existing packages in EPEL using the library (plasma-workspace and collectd-gps) and any 3rd party packages would still depend on the original gpsd-libs, even if they are rebuilt.

I think the proper solution is to disable the library in the main package. It's API/ABI is unstable, so it shouldn't be in EPEL at all. There are other packages that do that (frr). We can do that in EPEL10, but in EPEL8/9 we should keep the old package around, including the gpsd daemon, not just the library.