Re: Support installation to chroot and allows easier settings lib64 for plugins

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


-- 
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: