On Thu, Sep 21, 2017 at 12:49:13PM +0800, Harald Welte wrote: > > https://gerrit.osmocom.org/4003 > > 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 ack > 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. 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. > 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
signature.asc
Description: Digital signature
