Cellular Network Infrastructure » cni-legacy » OpenBSC

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.

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.

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.

ping? what's the status here?

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.

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).

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?

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.

neels wrote:

msuraev, please drop common_cs.h from the debian installation.

Sent for review in gerrit 3705

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.

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.