| Message ID | 1463059668-4884-1-git-send-email-emil.l.velikov@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series |
"Bump the major version"
( rev:
1
)
in
X.org (DEPRECATED - USE GITLAB) |
diff --git a/configure.ac b/configure.ac index 0505743..1d21d6e 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,7 @@ # Initialize Autoconf AC_PREREQ([2.60]) -AC_INIT([libICE], [1.0.9], +AC_INIT([libICE], [2.0.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [libICE]) AC_CONFIG_SRCDIR([Makefile.am]) AC_CONFIG_HEADERS([config.h]) diff --git a/src/Makefile.am b/src/Makefile.am index c69ee55..61b338a 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -6,7 +6,7 @@ AM_CFLAGS = \ $(ICE_CFLAGS) \ $(CWARNFLAGS) -libICE_la_LDFLAGS = -version-number 6:3:0 -no-undefined +libICE_la_LDFLAGS = -version-number 7:0:0 -no-undefined libICE_la_LIBADD = $(ICE_LIBS)
On Thu, 2016-05-12 at 14:27 +0100, Emil Velikov wrote: > With previous commits we've hidden a selection of internal symbols from > the DSO. Neither of them has been part of the API, although let's do the > sane thing and bump the major, as we might have changed things in a > backward incompatible way. I.e. we might have unintentionally broken > some applications. > > Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> > --- > Funny story... seems that the SONAME still uses the non-modular X > version (and it hasn't been bumped since the split) while configure > uses fresher numbers. Why should it have changed from non-modular to modular? All that changed was the build system, not the interface. > -libICE_la_LDFLAGS = -version-number 6:3:0 -no-undefined > +libICE_la_LDFLAGS = -version-number 7:0:0 -no-undefined The problem with bumping the soname for X libraries is there's multiple decades of binaries linked against the old names, which you will never be rid of. Bumping this here means everyone suddenly has to wonder why they have to build two copies of libICE. - ajax
On 12 May 2016 at 16:22, Adam Jackson <ajax@nwnk.net> wrote: > On Thu, 2016-05-12 at 14:27 +0100, Emil Velikov wrote: >> With previous commits we've hidden a selection of internal symbols from >> the DSO. Neither of them has been part of the API, although let's do the >> sane thing and bump the major, as we might have changed things in a >> backward incompatible way. I.e. we might have unintentionally broken >> some applications. >> >> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> >> --- >> Funny story... seems that the SONAME still uses the non-modular X >> version (and it hasn't been bumped since the split) while configure >> uses fresher numbers. > > Why should it have changed from non-modular to modular? All that > changed was the build system, not the interface. > I've assumed that there was a libICE release with the modular X version and then the version was decreased. Seems like that was never the case so all is fine. >> -libICE_la_LDFLAGS = -version-number 6:3:0 -no-undefined >> +libICE_la_LDFLAGS = -version-number 7:0:0 -no-undefined > > The problem with bumping the soname for X libraries is there's multiple > decades of binaries linked against the old names, which you will never > be rid of. Bumping this here means everyone suddenly has to wonder why > they have to build two copies of libICE. > Are you talking about a case where distro updates/rebuilds against vX, while some binary only solutions depend on vX-1 and the ways to distribute that ? Personally I'm fine either way - bump major, minor, patch, neither, just that dropping symbols does classify as ABI break, so major should be bumped. At least in theory. Proceed as you think it's better - I don't have even close to your experience dealing with X and its associated libs. -Emil
On Thu, May 12, 2016 at 14:27:48 +0100, Emil Velikov wrote: > With previous commits we've hidden a selection of internal symbols from > the DSO. Neither of them has been part of the API, although let's do the > sane thing and bump the major, as we might have changed things in a > backward incompatible way. I.e. we might have unintentionally broken > some applications. > > Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> > --- > Funny story... seems that the SONAME still uses the non-modular X > version (and it hasn't been bumped since the split) while configure uses > fresher numbers. > > Leaning that we should bump at least the SONAME one, although I've did > both just in case ;-) Very much against bumping SONAME. If you think that's needed as a result of these patches, then please rethink whether these patches are a good idea. Cheers, Julien
On 12 May 2016 at 17:19, Julien Cristau <jcristau@debian.org> wrote: > On Thu, May 12, 2016 at 14:27:48 +0100, Emil Velikov wrote: > >> With previous commits we've hidden a selection of internal symbols from >> the DSO. Neither of them has been part of the API, although let's do the >> sane thing and bump the major, as we might have changed things in a >> backward incompatible way. I.e. we might have unintentionally broken >> some applications. >> >> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> >> --- >> Funny story... seems that the SONAME still uses the non-modular X >> version (and it hasn't been bumped since the split) while configure uses >> fresher numbers. >> >> Leaning that we should bump at least the SONAME one, although I've did >> both just in case ;-) > > Very much against bumping SONAME. If you think that's needed as a > result of these patches, then please rethink whether these patches are a > good idea. > To avoid repeating myself I will kindly point you to my earlier reply. The gist - I don't mind either way. Please note that all but the first patch are cleanups ;-) I was just lazy enough to send 6 independent trivial/puny patches/emails. -Emil
On 12 May 2016 at 20:08, Emil Velikov <emil.l.velikov@gmail.com> wrote: > On 12 May 2016 at 17:19, Julien Cristau <jcristau@debian.org> wrote: >> On Thu, May 12, 2016 at 14:27:48 +0100, Emil Velikov wrote: >> >>> With previous commits we've hidden a selection of internal symbols from >>> the DSO. Neither of them has been part of the API, although let's do the >>> sane thing and bump the major, as we might have changed things in a >>> backward incompatible way. I.e. we might have unintentionally broken >>> some applications. >>> >>> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> >>> --- >>> Funny story... seems that the SONAME still uses the non-modular X >>> version (and it hasn't been bumped since the split) while configure uses >>> fresher numbers. >>> >>> Leaning that we should bump at least the SONAME one, although I've did >>> both just in case ;-) >> >> Very much against bumping SONAME. If you think that's needed as a >> result of these patches, then please rethink whether these patches are a >> good idea. >> > To avoid repeating myself I will kindly point you to my earlier reply. > The gist - I don't mind either way. > Just because I don't might which route is taken that doesn't mean that I won't appreciate any input on the topic. If you can reply to the respective thread that will be appreciated - specific symbol should/shouldn't be exported [1] or only package, SONAME, both or neither should be bumped [2] Thanks Emil [1] https://lists.freedesktop.org/archives/xorg-devel/2016-May/049622.html [2] https://lists.freedesktop.org/archives/xorg-devel/2016-May/049687.html
With previous commits we've hidden a selection of internal symbols from the DSO. Neither of them has been part of the API, although let's do the sane thing and bump the major, as we might have changed things in a backward incompatible way. I.e. we might have unintentionally broken some applications. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> --- Funny story... seems that the SONAME still uses the non-modular X version (and it hasn't been bumped since the split) while configure uses fresher numbers. Leaning that we should bump at least the SONAME one, although I've did both just in case ;-) --- configure.ac | 2 +- src/Makefile.am | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)