Bug#708584: versioning system/package name allows for binary incompatible libraries
On Mon, May 27, 2013 at 1:35 AM, Anton Gladky wrote: > Hi Scott, > > I have uploaded the 3.7.0-5 version into DELAYED/5 queue. Feel free > to cancel/reschedule or just let me know, if you find some issues in > this version. > > Best regards, > > Anton Looks good, I've been traveling so I couldn't look too closely at it - but that looks like a good solution. Don't worry about binNMUing qtiplot. There is another bug I'm working on there, the pending upload of qtiplot will build against the new alglib library. Thanks again. ~Scott -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708584: versioning system/package name allows for binary incompatible libraries
Hi Scott, I have uploaded the 3.7.0-5 version into DELAYED/5 queue. Feel free to cancel/reschedule or just let me know, if you find some issues in this version. Best regards, Anton 2013/5/22 Scott Howard : > On Fri, May 17, 2013 at 1:47 AM, Anton Gladky wrote: >> Hi, >> >> I have done this upload, sorry if I broke something or offended somebody. > > I'm the one that should apologize, I saw that you did contact me on > April 26, but I failed to respond. > >> >> Ok, if you want, I will create libalglib3.7.0. But I do not know, whether it >> is necessary for >> the package, having just qtiplot in build-rdeps and with popcon 33. But you >> are the >> main maintainer, you should decide. > > qtiplot's popcon is 1091, libalglib-2.6.0 popcon was several hundred, > libalglib3's popcon is 33. > In the past we had a problem where people did uploads to alglib that > broke alglib because they don't follow reasonable versioning. In fact, > alglib used to have a blurb on their website about how they don't > believe in build systems and everyone should hardcode their code into > projects. > > >> Why, actually, the version 2.6.0 has been uploaded into Debian on "06 Mar >> 2011", >> if it was half a year obsolete and unsupported by upstream? The version >> 3.3.0 was >> already available [1]. > > the only depending package in Debian required version 2.6.0, newer > versions broke that package, so we kept it until someone needed a > newer version (which is now, apparently). > >>> Does another package need it? >> >> >> Yes, not (yet) uploaded into Debian. > > this is a good reason to work it out. > >> >>> >>> 2) Why did a team upload switch from autotools to cmake? >> >> >> 3-versions are completely different from 2-vesions. It was rewritten from >> scratch. >> And yes, personal preferences. Why did you ask about that after uploading >> the >> package? > > Personal preference is ok, it is just something you avoid doing on NMU > and team uploads without checking with the maintainers first (which > you tried to do, but I missed the email) > I'm OK with cmake, could we set the "release" ldflag instead of > "version" as to not set the SONAME? I know how to do this in autotools > but not with cmake. This would be similar to how libalglib-2.6.0 did > it. > >> >>> >>> 3) Why did 1 and 2 happen without consulting with the current uploaders of >>> alglib or the depending package? >>> >> That is not true and I am surprised, that you decided to discuss it here: >> 1) I sent you and your co-maintainer an email with patches on alglib on >> April 26th. >> 2) May 5th the package has been uploaded into experimental. >> 3) May 15th, the package has been uploaded into unstable. >> >> The first communication with you was on May 16th. >> >> So I think, the second part of the bug is not RC. >> Again, sorry, if I broke something. I will try to be careful next time and >> ready for co-maintaining. > > Yes, I'm sorry I missed your email on the 26th. If I didn't turn you > off already, you're more than welcome to become an uploader/maintainer > of this package. > > I appreciate your work, sorry about the miscommunication. > > Regarding the RC part - we should consider how to future proof the > versioning. I prefer the "release" flag for alglib since they don't > use sane versioning [1]. We could set the SONAME to 3.7.0, like you > suggested, as well. In my opinion both are acceptable. If you'd like > to add yourself as an uploader and can choose which way you prefer. > > [1] http://www.sourceware.org/autobook/autobook/autobook_91.html > > Regards, > Scott -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708584: versioning system/package name allows for binary incompatible libraries
Hi Scott, 2013/5/22 Scott Howard : > I'm the one that should apologize, I saw that you did contact me on > April 26, but I failed to respond. No problem at all. I believe we will be able to maintain the library together successfully. > I'm OK with cmake, could we set the "release" ldflag instead of > "version" as to not set the SONAME? I know how to do this in autotools > but not with cmake. This would be similar to how libalglib-2.6.0 did > it. Could you, please, have a look at my commit [1]? It should be something similar as "-release" flag. I think we can make just "3.7" version without "0" at the end. It seems, upstream does not produce minor releases. What do you think? Thanks for constructive discussion. Anton [1] http://anonscm.debian.org/gitweb/?p=debian-science/packages/alglib.git;a=commitdiff;h=d579857bc2988070acc23840774ee138231bf5b0 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708584: versioning system/package name allows for binary incompatible libraries
On Fri, May 17, 2013 at 1:47 AM, Anton Gladky wrote: > Hi, > > I have done this upload, sorry if I broke something or offended somebody. I'm the one that should apologize, I saw that you did contact me on April 26, but I failed to respond. > > Ok, if you want, I will create libalglib3.7.0. But I do not know, whether it > is necessary for > the package, having just qtiplot in build-rdeps and with popcon 33. But you > are the > main maintainer, you should decide. qtiplot's popcon is 1091, libalglib-2.6.0 popcon was several hundred, libalglib3's popcon is 33. In the past we had a problem where people did uploads to alglib that broke alglib because they don't follow reasonable versioning. In fact, alglib used to have a blurb on their website about how they don't believe in build systems and everyone should hardcode their code into projects. > Why, actually, the version 2.6.0 has been uploaded into Debian on "06 Mar > 2011", > if it was half a year obsolete and unsupported by upstream? The version > 3.3.0 was > already available [1]. the only depending package in Debian required version 2.6.0, newer versions broke that package, so we kept it until someone needed a newer version (which is now, apparently). >> Does another package need it? > > > Yes, not (yet) uploaded into Debian. this is a good reason to work it out. > >> >> 2) Why did a team upload switch from autotools to cmake? > > > 3-versions are completely different from 2-vesions. It was rewritten from > scratch. > And yes, personal preferences. Why did you ask about that after uploading > the > package? Personal preference is ok, it is just something you avoid doing on NMU and team uploads without checking with the maintainers first (which you tried to do, but I missed the email) I'm OK with cmake, could we set the "release" ldflag instead of "version" as to not set the SONAME? I know how to do this in autotools but not with cmake. This would be similar to how libalglib-2.6.0 did it. > >> >> 3) Why did 1 and 2 happen without consulting with the current uploaders of >> alglib or the depending package? >> > That is not true and I am surprised, that you decided to discuss it here: > 1) I sent you and your co-maintainer an email with patches on alglib on > April 26th. > 2) May 5th the package has been uploaded into experimental. > 3) May 15th, the package has been uploaded into unstable. > > The first communication with you was on May 16th. > > So I think, the second part of the bug is not RC. > Again, sorry, if I broke something. I will try to be careful next time and > ready for co-maintaining. Yes, I'm sorry I missed your email on the 26th. If I didn't turn you off already, you're more than welcome to become an uploader/maintainer of this package. I appreciate your work, sorry about the miscommunication. Regarding the RC part - we should consider how to future proof the versioning. I prefer the "release" flag for alglib since they don't use sane versioning [1]. We could set the SONAME to 3.7.0, like you suggested, as well. In my opinion both are acceptable. If you'd like to add yourself as an uploader and can choose which way you prefer. [1] http://www.sourceware.org/autobook/autobook/autobook_91.html Regards, Scott -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708584: versioning system/package name allows for binary incompatible libraries
Hi, I have done this upload, sorry if I broke something or offended somebody. 2013/5/16 Scott Howard > Package: alglib > Version: 3.7.0-1~exp1 > Severity: serious > > the version of alglib is 3.7.0. Debian now is assigning a SONAME version > of 3. > This is incorrect as it implies all 3.x.x libraries are binary compatible, > which they are not. Upstream changelog explicitly states that not binary > 3.7.0 > and 3.6.0 are not binary compatible, for example. > > When assigning a SONAME version that differs from upstream, use the > "debian" > word in the SONAME. For example, 3debian0 would be an appropriate SONAME, > but > you would have to keep track of backwards incompatible changes to symbols > and > bump the next version when it comes out (e.g. 3debian1). If you don't do > this, > you risk making libraries that are incompatible with other distributions > and > upstream. That's why the old build system used the "-release @VERSION@" > flag > instead of "-version", so ensure that the soname remained blank. You can > assign > a SONAME to the library, but please append "debianX" or keep the old > system so > we can follow policy 8.2 "The run-time shared library must be placed in a > package whose name changes whenever the SONAME of the shared library > changes." > I preferred the old system since I didn't like assigning a SONAME that > upstream > was not using. > Ok, if you want, I will create libalglib3.7.0. But I do not know, whether it is necessary for the package, having just qtiplot in build-rdeps and with popcon 33. But you are the main maintainer, you should decide. > Other issues, not directly related to this bug, but somewhat at an RC > level so > we can take care of it before it migrates to testing: > 1) Why was alglib bumped at all? Why, actually, the version 2.6.0 has been uploaded into Debian on "06 Mar 2011", if it was half a year obsolete and unsupported by upstream? The version 3.3.0 was already available [1]. > Does another package need it? Yes, not (yet) uploaded into Debian. > Why was the new > version uploaded, breaking the only depending package in Debian without > first > checking with that package? > It was my fault, sorry. And I wrote you an email about that and fixed an issue already. > 2) Why did a team upload switch from autotools to cmake? > 3-versions are completely different from 2-vesions. It was rewritten from scratch. And yes, personal preferences. Why did you ask about that after uploading the package? > 3) Why did 1 and 2 happen without consulting with the current uploaders of > alglib or the depending package? > > That is not true and I am surprised, that you decided to discuss it here: 1) I sent you and your co-maintainer an email with patches on alglib on April 26th. 2) May 5th the package has been uploaded into experimental. 3) May 15th, the package has been uploaded into unstable. The first communication with you was on May 16th. So I think, the second part of the bug is not RC. Again, sorry, if I broke something. I will try to be careful next time and ready for co-maintaining. Cheers, Anton [1] http://www.alglib.net/arcnews.php#date_06_03_2011
Bug#708584: versioning system/package name allows for binary incompatible libraries
Package: alglib Version: 3.7.0-1~exp1 Severity: serious the version of alglib is 3.7.0. Debian now is assigning a SONAME version of 3. This is incorrect as it implies all 3.x.x libraries are binary compatible, which they are not. Upstream changelog explicitly states that not binary 3.7.0 and 3.6.0 are not binary compatible, for example. When assigning a SONAME version that differs from upstream, use the "debian" word in the SONAME. For example, 3debian0 would be an appropriate SONAME, but you would have to keep track of backwards incompatible changes to symbols and bump the next version when it comes out (e.g. 3debian1). If you don't do this, you risk making libraries that are incompatible with other distributions and upstream. That's why the old build system used the "-release @VERSION@" flag instead of "-version", so ensure that the soname remained blank. You can assign a SONAME to the library, but please append "debianX" or keep the old system so we can follow policy 8.2 "The run-time shared library must be placed in a package whose name changes whenever the SONAME of the shared library changes." I preferred the old system since I didn't like assigning a SONAME that upstream was not using. Other issues, not directly related to this bug, but somewhat at an RC level so we can take care of it before it migrates to testing: 1) Why was alglib bumped at all? Does another package need it? Why was the new version uploaded, breaking the only depending package in Debian without first checking with that package? 2) Why did a team upload switch from autotools to cmake? 3) Why did 1 and 2 happen without consulting with the current uploaders of alglib or the depending package? -- System Information: Debian Release: wheezy/sid APT prefers raring-updates APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 'raring-proposed'), (500, 'raring'), (100, 'raring-backports') Architecture: i386 (i686) Kernel: Linux 3.8.0-20-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
