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

[Scott Howard]

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