Bug#657393: RFS: skstream/0.3.6-1 [ITA] -- IOStream C++ socket Library
* Stephen M. Webb <stephen.webb@bregmasoft.ca>, 2012-01-26, 12:05:
* renamed binary packages due to SONAME change
But here are reverse-dependencies of the old binary package. Which
means that uploading this to unstable starts a transition. What this
discussed with the release team? It probably should, even though the
number of involved packages is small.
That said, the best moment to talk to the release team would be after
the package has been thoroughly reviewed (thus: not yet).
The old and new library packages are parallel-installable.
I consider this a feature,
Right, this is a property of every respectable shared library.
since the library is a part of an MMORPG stack, and I anticipate a
newer client app revision getting in to Debian long before a new server
app, so the coexistence of both old and new SONAMEs will be required,
at least for a little while.
Could elaborate more of this? What is "client app" and "server app" in
this context?
Please bear in mind that having multiple versions of the same source
package in a single suite is not really a desired state.
As far as unstable is concerned, you don't have control over when the
old package will be removed. While I think ftp-masters usually wait
until the old version don't have rdepeds anymore, they can also do it
whenever they see fit (possibly rendering not-yet-rebuilt packages
uninstallable).
Until very recently, it wasn't even possible (unless some dirty hacks
were involved) to keep multiple versions of a library in testing. It's
doable now, but such a state certainly doesn't make the Release Team
happy.
But, as you say, this will need to be discussed with the release team
after this package (and other upgraded packages in the stack) has been
thoroughly reviewed.
Great.
Does you new d/rules support DEB_BUILD_OPTIONS=noopt like the old one
did? Are you sure that there are no other regressions?
I have the greatest confidence that the dh sequencer support Debian
policy much better than the previous hand-rolled debian/rules script.
I have confirmed that the new debian/rules does indeed support
DEB_BUILD_OPTIONS=noopt and DEB_BUILD_OPTIONS=nostrip.
Did you build in unstable? I just did (with DEB_BUILD_OPTIONS=noopt),
and saw this in the build log:
/bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.. -I.. -g -O2 -Wall -DNDEBUG -c -o sksocket.lo sksocket.cpp
I would appreciate an explicit list of any apparent regressions, since
they aren't apparent to me from the build logs or runtime testing of
the package.
I didn't have anything specific in mind (except noopt support). Looking
at old debian/rules there are some things that dh certainly doesn't do:
- setting LDFLAGS=-lstdc++;
- passing --disable-debug to configure.
Maybe these were no-ops or simply wrong. Maybe not. I didn't check. :)
Now some things I didn't catch in my initial review:
The package descriptions were modified, but this is not documented in
the changelog.
The .orig.tar is compressed with bz2, but uscan would download a
.tar.gz. I see the upstream provides bzip2ed tarballs too, so it should
be a matter of fixing debian/watch.
--
Jakub Wilk
Reply to: