On 05/10/2015 09:02 PM, Felix Fietkau wrote: > On 2015-05-10 20:49, Thomas Strobel wrote: >> On 05/10/2015 02:48 PM, Felix Fietkau wrote: >>> On 2015-05-10 14:16, Thomas Strobel wrote: >>>>>> diff --git a/include/feeds.mk b/include/feeds.mk >>>>>> index 695b03b..27f3e8f 100644 >>>>>> --- a/include/feeds.mk >>>>>> +++ b/include/feeds.mk >>>>>> @@ -7,7 +7,7 @@ >>>>>> >>>>>> -include $(TMP_DIR)/.packagefeeds >>>>>> >>>>>> -FEEDS_AVAILABLE:=$(shell $(SCRIPT_DIR)/feeds list -n) >>>>>> +FEEDS_AVAILABLE:=$(perl $(SCRIPT_DIR)/feeds list -n) >>>>> I think this is the wrong place to make the change. Why not change >>>>> scripts/feeds to replace the #! line with: >>>>> #!/usr/bin/env perl >>>>> >>>>> - Felix >>>>> >>>>> >>>> Thanks for the review. >>>> Unfortunately, "/usr/bin/env" does not exist either. In NixOS there is >>>> no "/usr", no "/sbin", and only a "/bin/sh -> >>>> /nix/store/nixos_installation_specific_hash/bash". The absolute path to, >>>> e.g., "perl" or "env" is different for each installation of NixOS, so it >>>> can't be hard-coded into the build script. That's why I thought of >>>> calling "perl" directly from the PATH environment. >>> Then I think we should hold off on applying changes like the one you >>> proposed until we have a proper plan for dealing with the rest. >>> It needs to be possible to call ./scripts/feeds and similar scripts >>> directly. >>> How do other perl scripts on NixOS deal with that sort of stuff? >>> >>> - Felix >>> >>> >>> >> The way how NixOS deals with absolute path names in scripts is to patch >> every script. >> If software is packed for NixOS, then scripts are automatically or >> manually patched to execute under NixOS. >> For software that is not packed but only executed in NixOS, the scripts >> have to be adapted manually. > Ugh, that sounds really nasty.
Well, there's a price to pay for having a purely functional, declarative distribution with atomic upgrades and rollbacks ;). It's amazing when using the package manager of NixOS for software development, as you can, e.g., define a separate working environment for each project, especially as the environments are much more lightweight than Docker or LXC or all that. Have a look, the package manager is not restricted to NixOS but is also available for other Linux distributions and for OSX! >> As OpenWRT is just executed, the scripts have to be adapted manually for >> each new version or checkout of OpenWRT. The only reasonable way I can >> think of so far to fix the scripts in OpenWRT is at the calling side, >> like suggested in my patch. >> However, there are only 3-4 places that need changing in the build >> system and in a standard set of packages. So it wouldn't need too much >> tweaking on the OpenWRT side. > Given that the approach is incomplete (and quite inconvenient for > regular use), and any better fix will not need these changes at all, I > still object to adding them. > The way I see it, the issue of missing /usr/bin/env is going to come up > frequently with package-internal builds as well. NixOS users should > probably just create a symlink or wrapper script at /usr/bin/env, and we > should make sure that all important places in OpenWrt use it. > I really don't want to start adding more and more patches afterwards to > deal with the quirky non-standard behavior of NixOS. > > Changing the scripts in OpenWRT to use /usr/bin/env sounds like a pragmatic choice that would already make life easier under NixOS. In addition to changing the scripts, what do you think about referring to $(STAGING_DIR)/host/bin only for calling host binaries from OpenWRT scripts? That is, for calling "perl", the change would be: -FEEDS_AVAILABLE:=$(shell $(SCRIPT_DIR)/feeds list -n) +FEEDS_AVAILABLE:=$($(STAGING_DIR)/host/bin/perl $(SCRIPT_DIR)/feeds list -n) I know that this is very similar to what I proposed before, but it would have the benefit that there is a clear interface through which OpenWRT accesses any host binaries. Package-internal builds could be restricted to only access the host environment through $(STAGING_DIR)/host/bin as well, maybe helping to execute correctly once all requirements in $(STAGING_DIR)/host/bin are filled. - Thomas _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
