Re: Support installation to chroot and allows easier settings lib64 for plugins
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Thu, 14 May 2009 19:42:22 +1000
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:
