"scons all" only installs the freelan2 binary #59

Closed
leggewie opened this Issue Mar 16, 2015 · 16 comments

Projects

None yet

2 participants

@leggewie
Contributor

Did my first successful compilations, but scons does not seem to install anything much.

$ find install/ -type f
install/bin/freelan2

Is that really all?

@ereOn
Member
ereOn commented Mar 16, 2015

The installation target is platform agnostic. It only copies the generated binaries (and it happens that there is only one).

I guess we could extend that to copy the configuration files as well.

@ereOn ereOn added the enhancement label Mar 16, 2015
@ereOn ereOn added this to the 2.0 milestone Mar 16, 2015
@ereOn ereOn added the packaging label Mar 16, 2015
@ereOn
Member
ereOn commented Mar 20, 2015

@leggewie : The more I think of this, the more it seems to me that installing the configuration file is the responsibility of the packaging system/installer system, not the build system.

After all, the configuration files are not an artifact of the build system.

Do you see any reason why this should be done ?

@leggewie
Contributor

well, it seems to be standard practice. let me ask you back: "why bother with an install command at all if it's the responsability of the packager?"

@ereOn
Member
ereOn commented Mar 21, 2015

@leggewie

The main issue I have with that is that the installation phase takes a prefix but this doesn't work for Debian :

scons install --prefix=/usr/local

Where should the configuration file go ? Usually configuration files go to /etc/ but with the specified prefix, we are out of luck. Or is it acceptable to have the configuration file in say /usr/local/etc/ ? I would then need to change freelan's configuration file discovery to account for these cases (not a problem, I just say that as a reminder).

If you think this is acceptable, I'll change the installation phase this week-end.

@leggewie
Contributor

Sure that is acceptable. I maintain scanbd in Debian and that is how their default is. Obviously, for Debian I change that from /usr/local to /

@ereOn ereOn self-assigned this Mar 21, 2015
@ereOn
Member
ereOn commented Mar 21, 2015

@leggewie Good ! How do you "change" that ? Patch ? Compilation flag ?

What would be your preference ?

@ereOn
Member
ereOn commented Mar 21, 2015

@leggewie : I pushed to the configuration_as_build_artifact branch, the changes you requested.

Could you please let me know if that seems okay to you ?

Basically, here is what changed:

  • Calling scons install --prefix=/usr/local creates both /usr/local/bin/freelan2 and /usr/local/etc/freelan/freelan.cfg
  • On Windows, the etc/freelan/ part of the path is config/ instead.
  • The installation path is hardcoded in the binary (via a compilation flag generated for you automatically) : this installation path becomes the default (but you can obviously still use -c some/path/config.cfg to specify another one).

I believe those changes should ease the packaging phase, but I may have missed some things so please let me know :)

@leggewie
Contributor

I haven't tested this yet. I believe there are other files that should be shipped as well. But I guess they can be added later as necessary now that the plumbing seems to be in place.

Where is the default installation location? /usr/local? ./install/ as previously? I'm sorry, but I can't grok the change you made at this time of day. Good night.

@ereOn
Member
ereOn commented Mar 21, 2015

The "default" is indeed ./install because that's convenient when testing. I'd like to leave it that way if possible.

I assume it's not a problem since the packaing Makefile can just specify --prefix=/ instead.

No problem if you can't review it right away ;) Have a good night !

@leggewie
Contributor

"The installation path is hardcoded in the binary (via a compilation flag generated for you automatically)" Is that a relative or an absolute path? I don't think either will work, in fact. Debian often builds in a chroot, so the relative installation path would be debian/freelan/, for example, installing to debian/freelan/{etc,usr/sbin}. The binary package will then be installing to /etc and /usr/sbin

@leggewie
Contributor

seems like the hardcoding isn't creating an issue (at least that is my interpretation of ldd). freelan2 binary should be in /usr/sbin to be FHS-standard compliant (/usr/bin if freelan can be used by ordinary users). I think it would be nice if freelan2 retained the name of simply freelan.

@ereOn
Member
ereOn commented Mar 23, 2015

@leggewie Makes sense.

freelan can be used by ordinary users : they just won't be allowed to create/configure a tap adapter (but freelan can be used without one, in the case of non-members relays for instance).

I'm gonna change the following things this evening:

  • Add a --install_prefix option to the SCons scripts : --install_prefix will be the thing that gets hardcoded in the binary such that the package builder can just do : scons install --prefix=debian/freelan/ --install_prefix=/. The default for --install_prefix will be to take the same value as prefix so that from-source installs can just do : scons install --prefix=/usr/local.
  • Rename the binary from freelan2 to freelan

Would that be enough or is there anything else left to change to ease packaging ?

@ereOn ereOn added a commit that referenced this issue Mar 23, 2015
@ereOn ereOn Renamed freelan2 to freelan (#59) 8f2aefe
@leggewie
Contributor

The freelan binary should reside in /usr/bin, then. Does the program emit a warning when run without sufficient privileges and trying to create/configure a tap adapter?
I tested my Debian packages only briefly but it didn't look like the split into --prefix=debian/freelan/ and --install_prefix=/ was necessary. It might be possible to drop a1db80e before merging.

@ereOn
Member
ereOn commented Mar 24, 2015

@leggewie If the user tries to create a tap adapter but doesn't have the permissions to do so (he doesn't have to be root by the way, he can just have the CAP_NET_ADMIN capability), the program stops with a fatal error indicating that the tap adapter could not be created (not just a warning, since in this case FreeLAN cannot possibly reach its goals - it would be pointless to run without a tap adapter when the user explicitely asked for one)

Regarding the prefix thing, I'm confused:

"The installation path is hardcoded in the binary (via a compilation flag generated for you automatically)" Is that a relative or an absolute path? I don't think either will work, in fact. Debian often builds in a chroot, so the relative installation path would be debian/freelan/, for example, installing to debian/freelan/{etc,usr/sbin}. The binary package will then be installing to /etc and /usr/sbin

Can you describe to me the exact command you'd like to type in the packaging Makefile and the effect it should have ?

@leggewie
Contributor

I was theoreticizing. After doing the actual build I found out that this seemed to work as expected. I think it's safe to drop a1db80e.
Moving the binary to /usr/bin sounds like the thing to do.

@ereOn ereOn added a commit that referenced this issue Mar 29, 2015
@ereOn ereOn Renamed freelan2 to freelan (#59) 44b9410
@ereOn
Member
ereOn commented Mar 29, 2015

@leggewie Thanks for testing this !

I just merged those commits (except for a1db80e) in master.

@ereOn ereOn closed this Mar 29, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment