Bug#708584: versioning system/package name allows for binary incompatible libraries

[Anton Gladky]

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 <showard at debian.org>:
> On Fri, May 17, 2013 at 1:47 AM, Anton Gladky <gladky.anton at gmail.com> 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