[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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: