21 Sep
2017
21 Sep
'17
7:17 p.m.
On Thu, Sep 21, 2017 at 12:49:13PM +0800, Harald Welte wrote:
ack
The split off libosmo-mgcp-client still used headers from libosmo-legacy-mgcp.
After a 'make install', all of them are present, but from just a -client deb
package, they aren't.
I prefer to avoid this kind of interdependency, reminding me of
gsm_data_shared.h.
There still is one header file of shared code, but I want each library to have
its own copy of it. To avoid code dup, I want that copy to be made at
'make'-time -- ok because it's within the same git repository.
That is the main reason why I was waiting for the new version of
libosmo-mgcp-client to fix the osmo-msc deb package. This shared header needs
to be part of the deb.
After reading this, I will fix the osmo-msc.deb beforehand. I will copy the
shared header over, and put the sharing thereof in place after the new mgw has
been merged. We can then also discuss that part later.
I'm surprised about this. Why would an entirely new osmo-mgw
implementation be needed to build debian packages, if that
implementation is not yet reviewed and not yet used from either osmo-bsc
or osmo-msc master?
We can strip the addition of debian packages for later, if that's better.
If review
takes too long I am tempted to just merge it ahead to fix the state
of osmo-msc.deb in
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
Please don't. I've just spent a long time and have lots of review In fact, it has never gone through any review, and
your commit above has
been the first time this went into gerrit at all.
It's hopefully the last of the series of code bomb developments we faced this
year. I'm looking forward to normal gerrit patch submissions from then on.
The osmo-msc
currently fails because it needs a header file not included in
libosmo-mgcp-client-dev, because that is still tied to libosmo-mgcp headers,
which are of course not included in the libosmo-mgcp-client deb. I want them to
be separated completely to save us this kind of cumbersomeness in the future.
I'm not following. why were the untangling patches developed based on a
non-master branch of
very large ongoing development work, rather than on master?
I assumed we would go through it more quickly, maybe a misconception.
~N