Feature #2272
closedclarify: why does common_cs.h get installed by debian packaging?
Added by neels almost 7 years ago. Updated over 6 years ago.
20%
Description
openbsc/include/openbsc/common_cs.h is listed as noinst_HEADER.
However, it also appears in debian/openbsc-dev.install and is apparently installed.
This seems to magically work, although it shouldn't.
Related: gsm_data_shared.h includes <openbsc/common_cs.h>.
Related: until recently, the installed files were actually put in '$prefix/openbsc /*', i.e. with a trailing space in 'openbsc '. How did that not break our builds?
Related: when we added rest_octets.h to gsm_data_shared.h, the osmo-bts nightly packages build broke. https://gerrit.osmocom.org/2677
There appears to be some magic going on there that should not happen. Clarify what's going on there and why stuff works despite being broken. When this is done, all installed headers should be listed as such in the Makefile.am, debian should be able to package only installed headers, and a space in the 'openbsc ' installed dir should lead to build failures.
Updated by msuraev almost 7 years ago
- Priority changed from Normal to Low
This seems to magically work, although it shouldn't.
Why shouldn't? The obvious answer is that entries in debian/*.install have higher priority than noinst_HEADER. I don't have any reference from debian.org to back this up though - links are appreciated.
until recently, the installed files were actually put in '$prefix/openbsc /*'
Could you be more specific? In which files(s) was extra space? Which commits added/removed it?
all installed headers should be listed as such in the Makefile.am
What for? Aesthetic reasons or there'll be some improvement/fix for some scenario?
debian should be able to package only installed headers
Not sure I'm following this. Isn't it already package installed headers?
Setting priority to low as it might be made obsolete by BSC/MSC split in few months anyway.
Updated by neels almost 7 years ago
- Priority changed from Low to Normal
I think you could find out these things from looking at it more closely, but if you need it spelled out:
- In my understanding, debian packaging does a 'make install' to a temp dir and can only possibly include files in the package that were installed there during 'make install'. How then can we install a header file that is not listed in Makefile.am as installable. I might be wrong but we should be able to explain what is going on.
- A 'make install' should essentially be similar to a debian package installation. If we install files in the deb package that we don't from 'make install', that is confusing and wrong IMO. It should match. It should be obvious and not "magic", avoid as much obscurity as you can. I hope you agree there.
- The gerrit patch that fixes the trailing space: https://gerrit.osmocom.org/2649; correction, missing 'include' path element: $prefix/include/openbsc<space>.
But the actual question is: why does it not cause the build to fail when the installed headers are basically missing (aka at the wrong path). In other words, it seems that these headers don't even need to be installed in the first place??
- Finally, common_cs.h wasn't intended to be installed. Why does it need to be installed?
Putting priority back to normal because it should not take long to answer these questions. It is not clear yet when exactly we will move to the split git repositories. I would appreciate if you would clarify this instead of discarding the questions.
Updated by neels almost 7 years ago
- Priority changed from Normal to High
Any news here please? To be able to split up the openbsc.git repository, I need to know which dependencies are needed where. Please sort out this uncertainty and let me know the intention, instead of me trying to guess why things are the way they are and possibly breaking things without being aware.
Updated by msuraev over 6 years ago
I haven't double checked for references regarding my guess that "entries in debian/*.install have higher priority than noinst_HEADER" due to other work. I'm not sure what uses common_cs.h yet.
Updated by msuraev over 6 years ago
- % Done changed from 0 to 10
The common_cs.h is included by Neels (in ac1f1436e9d380f632dd850fcd253d3480f0fc2d) into gsm_data_shared.h so it have to be installed (even if initially it wasn't intended to).
Updated by msuraev over 6 years ago
It feels kinda odd that I'm answering to Neels' question regarding the header introduced by Neels with the ref to Neels' commit. Shall we cut the middle-man and just assign ticket to Neels?
Updated by neels over 6 years ago
msuraev wrote:
The common_cs.h is included by Neels (in ac1f1436e9d380f632dd850fcd253d3480f0fc2d) into gsm_data_shared.h so it have to be installed (even if initially it wasn't intended to).
common_cs.h added to gsm_data_shared.h was a mistake, i.e. I added the dependency by accident, thanks for spotting that. Including common_cs.h in the debian installation may have seemed like the logical consequence but was not intended, we should probably have had a chat about that back then... I reverted My commit ac1f1436 in https://gerrit.osmocom.org/3570.
msuraev, please drop common_cs.h from the debian installation.
Also please fix or clarify the other issues raised here.
Updated by msuraev over 6 years ago
- Status changed from New to In Progress
- % Done changed from 10 to 20
neels wrote:
msuraev, please drop common_cs.h from the debian installation.
Sent for review in gerrit 3705
Updated by msuraev over 6 years ago
- Status changed from In Progress to Feedback
- Assignee changed from msuraev to neels
neels wrote:
- In my understanding, debian packaging does a 'make install' to a temp dir and can only possibly include files in the package that were installed there during 'make install'.
What makes you think that? Do you have any reference to back it up?
There's nothing like that in https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html
'dh' tool wraps all the steps from autoreconf to install so it have access to any file in the package source tree and consequently can include any file in the package.
- The gerrit patch that fixes the trailing space: https://gerrit.osmocom.org/2649; correction, missing 'include' path element: $prefix/include/openbsc<space>.
But the actual question is: why does it not cause the build to fail when the installed headers are basically missing (aka at the wrong path). In other words, it seems that these headers don't even need to be installed in the first place??
Which build has not failed (but should)? Please be more specific. Gerrit 2649 says nothing about actual issue it's fixing.
Updated by neels over 6 years ago
- Status changed from Feedback to In Progress
msuraev wrote:
neels wrote:
- In my understanding, debian packaging does a 'make install' to a temp dir and can only possibly include files in the package that were installed there during 'make install'.
[...]
'dh' tool wraps all the steps from autoreconf to install so it have access to any file in the package source tree and consequently can include any file in the package.
Ok, so it can. As said above, IMHO it shouldn't install anything we don't have in our 'make install' step, because then 'make install' has a profoundly different effect than installing the debian package. I have said so before.
- The gerrit patch that fixes the trailing space: https://gerrit.osmocom.org/2649; correction, missing 'include' path element: $prefix/include/openbsc<space>.
But the actual question is: why does it not cause the build to fail when the installed headers are basically missing (aka at the wrong path). In other words, it seems that these headers don't even need to be installed in the first place??Which build has not failed (but should)? Please be more specific. Gerrit 2649 says nothing about actual issue it's fixing.
There was a space in a path installed by your debian package, meaning that the user, if any, should not have been able to find the headers. The point is that nothing failed, hence the installed files are obviously not needed by anyone anywhere. Hence: why are they even installed?
Max, it's a mystery to me how you can read all of the things I have written above and still flat out refuse to see the issues.
But congratulations, I guess you have successfully sat it out :P
I will frankly rather take a look myself to sort this out for the new repositories than spend any more time rephrasing questions that you discard.
IMPORTANT NOTICE: This page contains information about a legacy version of the Osmocom software. This legacy version is no longer maintained. If you use it, don't be surprised if it doesn't work. It was your choice to ignore man-years worth of developments, improvements and fixes. Please migrate to the active/supported software (Osmocom CNI, consisting of OsmoBSC, OsmoMSC, OsmoHLR, OsmoSTP, OsmoMGW - a NITB style setup is described at Osmocom_Network_In_The_Box).