Attention is currently required from: pespin, daniel. laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/31356 )

Change subject: Move libosmogsm TS 44.060 declarations under include/osmocom/gsm/ ......................................................................

Patch Set 2:

(2 comments)

Commit Message:

https://gerrit.osmocom.org/c/libosmocore/+/31356/comment/e52f7529_dbac30e6 PS2, Line 9: Currently there's a big mess where include dir osmocom/gprs/ is used by : both libosmogsm and libosmogb. I don't think that by itself constitues any mess. As long as the file names are unique, there's no problem. Within a project developed by a relatively small number of people, this should be feasible.

Given the deprecation fall-out you're aiming to create with this (and even more so the follow-up patch of renaming the include dir), I'm really wondering if it wouldn't be much easier, and without any risk of breakage/fall-out to old aplications, if the new library (libosmo-gprs) would simply use a different include path. This has much less impact on applications, as almost nobody is using applications for that new library, right?

https://gerrit.osmocom.org/c/libosmocore/+/31356/comment/c6750124_fd1acac9 PS2, Line 30: can eventually get rid of them. and eventuall break building old applications, which we generally try not to, unless it's really impossible to fix an important bug without it. I'm doubtful naming and location of header files is an "impossible to fix important bug" qualifies as that.

So if we introduce something for backwards compatibility, we should assume it is here to stay, and not just temporary.