Created attachment 85928 [details] Demonstrate non-hardcoded equal enum values Hello there! Gegl [1] from the Gimp universe is using libopenraw. In the latest release, enum value OR_DATA_TYPE_CFA is used [2]. The libopenraw master branch has removed that constant from the or_cfa_pattern enum, see [3]. My understanding is that you are doing ABI-incompatible changes from 0.0.9 to 0.1.0 already, intentially I suppose. I wonder if breaking source-compatibily is really needed or intended, though. Please share your intentions. With my current understating, I would ask you to: 1. Bring back OR_DATA_TYPE_CFA with original value. This approach seems to work well: typedef enum { OR_DATA_TYPE_NONE = 0, OR_DATA_TYPE_PIXMAP_8RGB, /**< 8bit per channel RGB pixmap */ OR_DATA_TYPE_PIXMAP_16RGB, /**< 16bit per channel RGB pixmap */ OR_DATA_TYPE_JPEG, /**< JPEG data */ OR_DATA_TYPE_TIFF, /**< TIFF container */ OR_DATA_TYPE_PNG, /**< PNG container */ OR_DATA_TYPE_RAW, /**< RAW container */ OR_DATA_TYPE_CFA = OR_DATA_TYPE_RAW, /* DEPRECATED */ OR_DATA_TYPE_COMPRESSED_RAW, /**< compressed RAW container */ OR_DATA_TYPE_UNKNOWN } or_data_type; I'm attaching enum_demo.c to demonstrate. Run like this: # gcc -std=c89 -Wall -Wextra -pedantic -o enum_demo{,.c} && ./enum_demo OR_DATA_TYPE_PNG 5 OR_DATA_TYPE_RAW 6 OR_DATA_TYPE_CFA 6 OR_DATA_TYPE_COMPRESSED_RAW 7 OR_DATA_TYPE_UNKNOWN 8 If you have concerns with that, adding #define OR_DATA_TYPE_CFA OR_DATA_TYPE_RAW might do, as well. 2. Add version defines accessible from <libopenraw/libopenraw.h> so that software compiling against libopenraw has a chance to do version-specific things. In configure.ac you already have soname part constants: AC_SUBST([LIBOPENRAW_REVISION], [0]) AC_SUBST([LIBOPENRAW_AGE], [0]) AC_SUBST([LIBOPENRAW_CURRENT], [7]) Exposing those through libopenraw.h would be cool. I am unsure if those numbers are better or worse than the actual version numbers. If you're in doubt too, adding both wouldn't hurt. I am happy to make a dedicated bug report for version defines if you prefer. Since the we're using a both 0.0.9 and a post-0.0.9 snapshot of libopenraw in Gentoo Linux (to get post-release bugfixes to our user base) the departure of OR_DATA_TYPE_CFA is a real problem [4]. We will need to make some decision downstream ourselves soon. The sooner we know about your intentions, the better for us. Would be great to hear from you soon. Many thanks! Sebastian [1] http://www.gegl.org/ [2] https://git.gnome.org/browse/gegl/tree/operations/external/openraw.c#n119 [3] http://cgit.freedesktop.org/libopenraw/tree/include/libopenraw/consts.h#n74 [4] https://bugs.gentoo.org/show_bug.cgi?id=483562
The Gentoo bug is invalid: they use unreleased software that has no guarantee of compatibility. git master break both ABI and API. There is no discussion. It has always been that The only bug in there is the name of the .pc file and the snafu that it will entails in the future. I'll fix that. I might actually provide a "get version" API, this will actually allow do detect a runtime mess.
Change the .pc name to lift ambiguity. http://cgit.freedesktop.org/libopenraw/commit/?id=0ca41734ca58fb9f23f7e20b9ef76005c43f4e17
(In reply to comment #1) > The Gentoo bug is invalid: they use unreleased software that has no > guarantee of compatibility. Packaging off-release code is a risk to downstream, right. Any chance for a soon release of 0.1.0 so we can get off the snapshot downstream? > git master break both ABI and API. There is no discussion. It has always > been that How is software using libopenraw supposed to work with more than a single version of libopenraw then? If you have two pieces of software using libopenraw that means you can only use their releases using the same version of libopenraw. Afaik, most library projects try to break ABI and API as seldom as possible. Why would libopenraw be the exception? > The only bug in there is the name of the .pc file and the snafu that it will > entails in the future. I'll fix that. That doesn't really seem related to me. How does it relate? > I might actually provide a "get version" API, this will actually allow do > detect a runtime mess. A runtime version check is nice to have, but we need is a compile time version more. Any chance that could be added? Please re-open the bug report. Thank you.
http://cgit.freedesktop.org/libopenraw/commit/?id=c908238289e8ad571246a91ad2e6113f2d4d79dc
(In reply to comment #3) > (In reply to comment #1) > > The Gentoo bug is invalid: they use unreleased software that has no > > guarantee of compatibility. > > Packaging off-release code is a risk to downstream, right. it is a risk to upstream too. This bug is exhibit 1. > Any chance for a soon release of 0.1.0 so we can get off the snapshot > downstream? For a loose definition of "soon". > How is software using libopenraw supposed to work with more than a single > version of libopenraw then? I just fixed that in the current tree. Again, master was unreleased, so instead of checking that things were work > libopenraw that means you can only use their releases using the same version > of libopenraw. Afaik, most library projects try to break ABI and API as > seldom as possible. Why would libopenraw be the exception? Not sure which planet you leave on, but there is a metric fuckton of breakage happening on STABLE libraries of various origins. libopenraw hasn't reached the stable stage at all. Also, shall I repeat one more time that you were packaging master and not even a pre-release tarball? It is like selling a prototype consumers and wondering why it breaks. > > The only bug in there is the name of the .pc file and the snafu that it will > > entails in the future. I'll fix that. > That doesn't really seem related to me. How does it relate? You talk about parallel installable versions. This is related. Followup commit did change the header install path. > > I might actually provide a "get version" API, this will actually allow do > > detect a runtime mess. > > A runtime version check is nice to have, but we need is a compile time > version more. What do you thing the .pc file are for? Ornamental purpose? One thing I'm sure now is that I will really have the need to add a runtime version check to work around that kind of downstream fuck ups. And I thought only Debian/Ubuntu was silly to think shipping the development version was a good idea.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.