This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Fri, Sep 01, 2017 at 05:01:14PM +0200, Max wrote:
> On 31.08.2017 13:56, Harald Welte wrote:
> > Not so sure if that would really simplify it. What would be a good idea is
> > an explicit --{enable-disable}-gtp for old openbsc.git and an unconditional dependency
> > from the new osmo-sgsn.git repository to avoid the "silently built without SGSN support"
> > behavior.
>
> From the point of release automation - it certainly would: right now we treat each
> repo either as a library or as a non-library project. This allows us to generate
> meaningful changelogs and check for things like missing API/ABI libversion bump.
>
> Supporting both in the same repo would make helper code much more complex. AFAIK
> OpenGGSN is the only Osmocom project which produces both library and non-library
> packages.
* We have the osmo-hnbgw program being installed from the "library project"
osmo-iuh (or is it a program project also installing libosmo-ranap?);
* we have the osmo-stp program coming from libosmo-sccp;
* we now have osmo-mgw.git installing both the osmo-bsc_mgcp
program as well as libosmo-legacy-mgcp (to-be osmo-mgw and libosmo-mgcp);
* libosmocore installs osmo-auc-gen...
and I'm fairly sure we can find more mixed library/program instances.
If we really require to strictly treat git trees as *either* library *or*
program project, we would need to do a lot more splitting. It seems to me that
we unfortunately rather should have more complex helpers instead.
I'll soon bump the new osmo-{msc,bsc,mgw,sgsn} repositories to version 2.0.0,
so I need to look at the new release process anyway. Let me comment on that in
a separate mail. I hope that I will thus gain a better understanding of the
difference or complexity from mixing libraries with programs.
(https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release)
I still want some more tweaks to go into the new repositories before bumping,
but can review releasing now as good as any other time.
> > The osmo-sgsn rename is something I've been pondering in the laforge/osmo-sgsn
* I assume typo: osmo-ggsn
> > branch where the VTY is introduced. I've almost decided against it meanwhile,
> > given that > 90% of the code still is OpenGGSN code, and credit belongs to the
> > creators of that and not to Osmocom.
If we are the sole maintainers now, it makes sense to embed openggsn in our
naming scheme of osmo-* and libosmo-*, especially when openbsc.git is gone. We
should still credit the origins in README and/or header comments of course.
There is some sense in separating lib(osmo-)gtp from the GGSN, i.e. that
building osmo-sgsn only needs the GTP lib and not the GGSN binary. But I have
listed numerous similar instances above, so no real reason to split.
IOW, install libosmo-gtp and osmo-ggsn from a joint osmo-ggsn.git. But I'm
unsure about: if we rename libgtp to libosmo-gtp, do we confuse the hell out of
the rest of the world? So far I found 'libgtp' confusing ("is it osmocom??").
In any case, this now is an ideal time to do renames like this, while we're
busy rejiggering half the core network anyway. It will just be part of the new
way that everyone needs to adjust to.
~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20170902/43f89acb/attachment.bin>