Re: Support installation to chroot and allows easier settings lib64 for plugins
- From: Josef Reidinger <jreidinger@xxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Thu, 14 May 2009 13:10:56 +0200
tpgww@xxxxxxxxxxx wrote:
> On Thu, 14 May 2009 09:20:07 +0200
> Josef Reidinger <jreidinger@xxxxxxx> wrote:
>
>> tpgww@xxxxxxxxxxx wrote:
>>> On Wed, 13 May 2009 12:53:32 +0200
>>> josef reidinger <jreidinger@xxxxxxx> wrote:
>>>
>>>> tpgww@xxxxxxxxxxx napsal(a):
>>>>> On Tue, 12 May 2009 15:32:30 +0200
>>>>> Josef Reidinger <jreidinger@xxxxxxx> wrote:
>>>>>
>>>>>> I attached patch with allows easier packaging of emelfm2. It is needed
>>>>>> correct lib directory on 64-bit machines for some distros and also
>>>>>> installation to chroot.
>>>>> Josef,
>>>>>
>>>>> LIB_DIR is already supported, as you've proposed, in svn.
>>>>>
>>>>> You can change the PREFIX variable for the install phase, doesn't have
>>>>> the same effect as your DESTDIR ?
>>>> I think that this affect finding plugins as PREFIX is constant in
>>>> build.h which is used in code. So after long prefix is plugin finded at
>>>> bad place (build is in chroot but target is installed without chroot
>>>> prefix). At least it show warning that in code is hardcoded chroot path.
>>>> I can test it if you need test case.
>>> PREFIX specified in build.h has no effect on installation, or vice-versa.
>>>
>>> In the patch you sent, every instance of $(DESTDIR) can be handled by a
>>> change of PREFIX (in effect, set PREFIX = $(DESTDIR)$(PREFIX)) for
>>> installation, like:
>>> make .... PREFIX=<whatever> ....
>>> make install .... PREFIX=DESTDIR<whatever> ....
>>>
>>> So I'm not quite sure what you're trying to work around. Please describe a
>>> test case, as you suggested.
>> Yes, no affect on installation but in runtime it is problem. We build
>> packages in chroot and separate dir to catch all file creation. So
>> package is installed to directory /tmp/build/emelfm2-.../ which is
>> simulated root for package and can easy track any files which is created
>> and which own this package. But emelfm2 store some constants about
>> plugins path PLUGINS_DIR which also contain PREFIX...and after build and
>> installation to target system is plugin loaded from location
>> /tmp/build/emelfm2-.../usr/lib/emelfm2/ which of course doesn't exist on
>> target system. So DESTDIR is constant which is used only to install to
>> build root, which is not included during runtime. I hope I describe it.
>> As test case you can has chroot enviroment and try install to it. If you
>> chroot into it and try run emelfm2 it doesn't find plugins dir.
>
> Joseph, different build- and install- prefixes are used for every rpm I've
> ever built. For example, make with PREFIX /usr, and install with PREFIX
> /usr/src/rpm/tmp/emelfm2-buildroot/usr. This seems to be essentially the same
> as you've described. There's never been any problem with the plugins being
> found or loaded.
>
> There must be something about your chroot-build process that I'm not seeing.
> Even if you chroot to something like /tmp/build/emelfm2-build before make
> etc, there should be no impact on paths hard-coded during compilation. Those
> paths are just derived strings, not related to the layout of the filesystem.
> Installation (to anywhere) doesn't change those strings. I think that
> incorrect paths can only get into the code if you 'make PREFIX=wrong'! If you
> don't ever need to worry about /tmp/build/emelfm2-build prefix because of a
> chroot, probably you'd just 'make PREFIX=/usr other args...' then 'make
> install PREFIX=/usr'.
>
> In any event, I still can't figure out what net difference comes from
> applying a DESTDIR variable. Although arguably it might be a bit easier to
> understand the Makefile process, that way.
>
> Staying with plugins as an example, Makefile currently has
>
> install -m 755 $$file $(PLUGINS_DIR);
>
> where PLUGIN_DIR defaults to $(LIB_DIR)/$(TARGET)/plugins
> which in turn defaults to $(PREFIX)/lib/emelfm2/plugins
> and then to /usr/local/lib/emelfm2/plugins
>
> For the purposes of this discussion, assume no chroot or change to these
> defaults for building, but a change during installation:
>
> make install PREFIX=/tmp/build/emelfm2-build/usr/local
>
> So we get
>
> install -m 755 $$file /tmp/build/emelfm2-build/usr/local/lib/emelfm2/plugins
>
> If instead, Makefile had your patch, hence
>
> install -m 755 $$file $(DESTDIR)$(PLUGINS_DIR);
>
> and we used
>
> make install DESTDIR=/tmp/build/emelfm2-build
>
> The result is the same:
>
> install -m 755 $$file /tmp/build/emelfm2-build/usr/local/lib/emelfm2/plugins
>
> What am I missing ?
>
> Regards
> Tom
>
>
at src/e2_main.c:680 is Plugin *p = e2_plugins_open1 (PLUGINS_DIR
G_DIR_SEPARATOR_S UPGRADE_PNAME);
PLUGINS_DIR is from build.h
@echo "#define PLUGINS_DIR \"$(PLUGINS_DIR)\"" >> $(BUILD_FILE)
So if I understand code then plugin is open at
/tmp/build/emelfm2-build/usr/local/lib/emelfm2/plugins during execution
as this constant is static. I has been warned by rpmling which find
build path hardcoded to code. So exist two options...this line is not
used or it somehow is smarted then I think.
--
Users can unsubscribe from the list by sending email to
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by
logging into the web interface.
Other related posts:
