beta3-2

[Barth Netterfield]

I have repackaged beta 3, with the build system set to call the libraries
libkst2*.so, so there should be no problem with either building or installing
with kst1.x installed.

the new package is at
http://galadriel.astro.utoronto.ca/kst/kst-2.0.0-beta3-2.tgz

I plan to upload Thursday.

cbn
_______________________________________________
Kst mailing list
Kst@...
https://mail.kde.org/mailman/listinfo/kst

On Tue, Oct 06, 2009 at 08:37:46PM -0400, Barth Netterfield wrote:

> I have repackaged beta 3, with the build system set to call the libraries
> libkst2*.so, so there should be no problem with either building or installing
> with kst1.x installed.
>
> the new package is at
> http://galadriel.astro.utoronto.ca/kst/kst-2.0.0-beta3-2.tgz
>
> I plan to upload Thursday.
>
> cbn

./build_kst worked here on Slackware, so that's an improvement.

The INSTALL instructions are vague on how to build a packageable version.
Is a DESTDIR-like thing supported?  Is that what's called OUTPUT_DIR
passed to ./install-kst?  That one doesn't seem to do anything.

Looking at the qmake generated makefiles seem to indicate I should set
the envirnomental variable INSTALL_ROOT; so let's try creating a kst
that will eventually be installed in /absolute/prefix, but that I want
to stage, for packaging reasons in /dest/dir (ie. so everything will be
installed in /dest/dir/absolute/prefix/*)  I tried:

$ INSTALL_ROOT=/dest/dir ./install-kst anything-but-debug /absolute/prefix

almost works.  It installs things in /dest/dir/* instead of the intended
/dest/dir/absolute/prefix/*.  (ie. setting INSTALL_ROOT ignores
INSTALL_PREFIX.)

As an aside, you should point out in the INSTALL document that the
INSTALL_PREFIX passed to ./install-kst should be an absolute path or
weirdness will ensue.  (The particular weirdness is things get installed
in the src tree.)

Doing something like

$ ./install-kst still-not-debug /some/path/not/usr

properly installs kst2 in /some/path/not/usr, but the executable can't
be run, because there are no RPATHs in it pointing to
/some/path/not/usr/lib .

Cheers,
-dvw
--
Don Wiebe                                   dvw@...
Department of Physics and Astronomy
University of British Columbia
6224 Agricultural Road                      Tele: [phone]
University Endowment Lands, BC
Canada   V6T 1Z1                            http://ketiltrout.net/


_______________________________________________
Kst mailing list
Kst@...
https://mail.kde.org/mailman/listinfo/kst

[Barth Netterfield]

I'm not sure I understand.

why not
./install-kst release /dest/dir/absolute/prefix

Assuming /absolute/prefix/lib is in ld.so.conf, everything should work fine
when you unroll the package, shouldn't it?

cbn

On Tuesday 06 October 2009 21:17:00 D. V. Wiebe wrote:

> Looking at the qmake generated makefiles seem to indicate I should set
> the envirnomental variable INSTALL_ROOT; so let's try creating a kst
> that will eventually be installed in /absolute/prefix, but that I want
> to stage, for packaging reasons in /dest/dir (ie. so everything will be
> installed in /dest/dir/absolute/prefix/*)  I tried:
>
> $ INSTALL_ROOT=/dest/dir ./install-kst anything-but-debug /absolute/prefix
>
> almost works.  It installs things in /dest/dir/* instead of the intended
> /dest/dir/absolute/prefix/*.  (ie. setting INSTALL_ROOT ignores
> INSTALL_PREFIX.)
>
> As an aside, you should point out in the INSTALL document that the
> INSTALL_PREFIX passed to ./install-kst should be an absolute path or
> weirdness will ensue.  (The particular weirdness is things get installed
> in the src tree.)
>
> Doing something like
>
> $ ./install-kst still-not-debug /some/path/not/usr
>
> properly installs kst2 in /some/path/not/usr, but the executable can't
> be run, because there are no RPATHs in it pointing to
> /some/path/not/usr/lib .
>
> Cheers,
> -dvw
>

_______________________________________________
Kst mailing list
Kst@...
https://mail.kde.org/mailman/listinfo/kst

On Thu, Oct 08, 2009 at 10:21:50AM -0400, Barth Netterfield wrote:
> I'm not sure I understand.
>
> why not
> ./install-kst release /dest/dir/absolute/prefix
>
> Assuming /absolute/prefix/lib is in ld.so.conf, everything should work fine
> when you unroll the package, shouldn't it?
>
> cbn

I suppose that would work, so long as none of the files that get install
have $PREFIX hard-coded in them.  If it does, you'd get the situation that kst
would be looking in the (probably non-existant) $DESTDIR/$PREFIX for things
instead of the $PREFIX.

I think packagers prefer to assume that the installed programs do indeed
contain references to $PREFIX, and, as a result, prefer to separate $PREFIX
from $DESTDIR, to be sure that the installed files can't be contaminated by
$DESTDIR.

-dvw

> On Tuesday 06 October 2009 21:17:00 D. V. Wiebe wrote:
> > Looking at the qmake generated makefiles seem to indicate I should set
> > the envirnomental variable INSTALL_ROOT; so let's try creating a kst
> > that will eventually be installed in /absolute/prefix, but that I want
> > to stage, for packaging reasons in /dest/dir (ie. so everything will be
> > installed in /dest/dir/absolute/prefix/*)  I tried:
> >
> > $ INSTALL_ROOT=/dest/dir ./install-kst anything-but-debug /absolute/prefix
> >
> > almost works.  It installs things in /dest/dir/* instead of the intended
> > /dest/dir/absolute/prefix/*.  (ie. setting INSTALL_ROOT ignores
> > INSTALL_PREFIX.)
> >
> > As an aside, you should point out in the INSTALL document that the
> > INSTALL_PREFIX passed to ./install-kst should be an absolute path or
> > weirdness will ensue.  (The particular weirdness is things get installed
> > in the src tree.)
> >
> > Doing something like
> >
> > $ ./install-kst still-not-debug /some/path/not/usr
> >
> > properly installs kst2 in /some/path/not/usr, but the executable can't
> > be run, because there are no RPATHs in it pointing to
> > /some/path/not/usr/lib .
> >
> > Cheers,
> > -dvw
> >

--
Don Wiebe                                   dvw@...
Department of Physics and Astronomy
University of British Columbia
6224 Agricultural Road                      Tele: [phone]
University Endowment Lands, BC
Canada   V6T 1Z1                            http://ketiltrout.net/


_______________________________________________
Kst mailing list
Kst@...
https://mail.kde.org/mailman/listinfo/kst

> > I'm not sure I understand.

> >
> > why not
> > ./install-kst release /dest/dir/absolute/prefix
> >
> > Assuming /absolute/prefix/lib is in ld.so.conf, everything should work fine
> > when you unroll the package, shouldn't it?
> >
> > cbn
>
> I suppose that would work, so long as none of the files that get install
> have $PREFIX hard-coded in them.  If it does, you'd get the situation that kst
> would be looking in the (probably non-existant) $DESTDIR/$PREFIX for things
> instead of the $PREFIX.
>
> I think packagers prefer to assume that the installed programs do indeed
> contain references to $PREFIX, and, as a result, prefer to separate $PREFIX
> from $DESTDIR, to be sure that the installed files can't be contaminated by
> $DESTDIR.

As long as the ./build-kst step can be done immediately before that and
doesn't have to know about /dest/dir, then it's cool by me (and as long
as ./install-kst actually just installs things and doesn't compile some
more or create/edit config files).  

--
"Party on Wayne; Party on Garth. -- Wayne's World"
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt@...
http://matt.truch.net/


_______________________________________________
Kst mailing list
Kst@...
https://mail.kde.org/mailman/listinfo/kst

On Thu, Oct 08, 2009 at 04:48:03PM -0400, Matthew D Truch wrote:

> > > I'm not sure I understand.
> > >
> > > why not
> > > ./install-kst release /dest/dir/absolute/prefix
> > >
> > > Assuming /absolute/prefix/lib is in ld.so.conf, everything should work fine
> > > when you unroll the package, shouldn't it?
> > >
> > > cbn
> >
> > I suppose that would work, so long as none of the files that get install
> > have $PREFIX hard-coded in them.  If it does, you'd get the situation that kst
> > would be looking in the (probably non-existant) $DESTDIR/$PREFIX for things
> > instead of the $PREFIX.
> >
> > I think packagers prefer to assume that the installed programs do indeed
> > contain references to $PREFIX, and, as a result, prefer to separate $PREFIX
> > from $DESTDIR, to be sure that the installed files can't be contaminated by
> > $DESTDIR.
>
> As long as the ./build-kst step can be done immediately before that and
> doesn't have to know about /dest/dir, then it's cool by me (and as long
> as ./install-kst actually just installs things and doesn't compile some
> more or create/edit config files).  

I assumed you had to build an installable version of kst2 with
./install-kst instead of ./build-kst to avoid the insertion of
build-path RPATHs in the binary.  (To prevent the trojan problem).

I haven't looked through the source, but running strings on all the
files that ended up in the install directory didn't come up with any
instances of the install path, so maybe Barth's suggestion is sufficient?

Cheers,
-dvw
--
Don Wiebe                                   dvw@...
Department of Physics and Astronomy
University of British Columbia
6224 Agricultural Road                      Tele: [phone]
University Endowment Lands, BC
Canada   V6T 1Z1                            http://ketiltrout.net/


_______________________________________________
Kst mailing list
Kst@...
https://mail.kde.org/mailman/listinfo/kst

Okay, I've successfully managed to make a package for slackware-current.
It installs to /usr and runs fine.  I detect no staging directory
contamination.

The process was complicated by the fact that my package build system
requires the build of the package to happen outside the directory
hiearchy of the source tarball.  As a result, I can't use ./install-kst
and friends to build it.  Nevertheless, here's a cartoon of my process:

1) Upack the source in /tmp/kst-source:

$ cd /tmp/kst-source
$ tar -zxvf $UPSTREAMDIR/kst-2.0.0-beta3-2.tgz

2) Build the package in /tmp/kst-build/, and stage the resulting file
hiearchy in /tmp/kst-package/, for later installation in /usr:

$ cd /tmp/kst-build
$ export OUTPUT_DIR=$PWD                     # build dir
$ exprot INSTALL_PREFIX=/tmp/kst-package/usr # staging-dir/prefix-dir
$ export INSTALL_LIBDIR=lib                  # libdir under prefix
$ export KST_DEBUG_MODE=0                    # non-debug build
$ qmake -r /tmp/kst-source/kst/kst-2.0.0-beta3-2/kst.pro
$ make
$ make install

Which resulted in a properly staged package hiearchy in /tmp/kst-package,
after which it can be tar'd/cpio'd/ar'd/what-have-you'd into a package.

This process would be made more easy if the INSTALL docuement were
modified to:

- explain that OUTPUT_DIR should be the *build* directory of the package.
  In fact, since ./install-kst hard-codes the build directory to ./build,
  you might want to explain when passing OUTPUT_DIR to install-kst is
  useful.  (I can't see the instance, myself.)
- for packagers who are used to the common "./configure; make; make
  install" deal, explicitly point out that, if desired, INSTALL_PREFIX
  may include a staging directory (what autotools would call DESTDIR), in
  addition to the installation prefix itself (what autotools would call
  PREFIX), ie. "$DESTDIR/$PREFIX"
- add an explicit example for distro package maintainers, along the
  lines of:

      Create a package staged in /tmp/package/ for later installation
      in /usr:

      1. Follow Linux build steps 1-3
      2. ./install-kst release /tmp/package/usr

  (This is probably sufficient to take care of the point about
  INSTALL_PREFIX above).
- And as a minor nitpick: wrap lines longer than 80 characters.  The
  current run-on lines do not make it easier to read the document,
  especially since some of the >80 character lines are in paragraphs
  which are left-indented.

Cheers,
-dvw
PS. Regarding the kst2/kst name debate: I just had the package create a
symlink kst -> kst2 in the bin directory upon install.  This prevents
installing both kst1 and kst2 side-by-side, but the operation could be
made more clever to support that (by, for instance, not creating the
symlink if kst1 exists).
--
Don Wiebe                                   dvw@...
Department of Physics and Astronomy
University of British Columbia
6224 Agricultural Road                      Tele: [phone]
University Endowment Lands, BC
Canada   V6T 1Z1                            http://ketiltrout.net/


_______________________________________________
Kst mailing list
Kst@...
https://mail.kde.org/mailman/listinfo/kst

> 2) Build the package in /tmp/kst-build/, and stage the resulting file

> hiearchy in /tmp/kst-package/, for later installation in /usr:
>
> $ cd /tmp/kst-build
> $ export OUTPUT_DIR=$PWD                     # build dir
> $ exprot INSTALL_PREFIX=/tmp/kst-package/usr # staging-dir/prefix-dir
> $ export INSTALL_LIBDIR=lib                  # libdir under prefix
> $ export KST_DEBUG_MODE=0                    # non-debug build
> $ qmake -r /tmp/kst-source/kst/kst-2.0.0-beta3-2/kst.pro
> $ make
> $ make install
>
> Which resulted in a properly staged package hiearchy in /tmp/kst-package,
> after which it can be tar'd/cpio'd/ar'd/what-have-you'd into a package.

For fedora, where the "staging-dir" is not allowed to be disclosed
during the "compile" step, only during the install step, I tried to do
this in a slightly different order:

# Compile step
$ cd /tmp/kst-build
$ export OUTPUT_DIR=$PWD                     # build dir
$ export KST_DEBUG_MODE=0                    # non-debug build
$ qmake -r /tmp/kst-source/kst/kst-2.0.0-beta3-2/kst.pro
$ make
# Install step
$ export INSTALL_PREFIX=/tmp/kst-package/usr # staging-dir/prefix-dir
$ export INSTALL_LIBDIR=lib                  # libdir under prefix
$ make install

Which doesn't work as expected; it ignores the staging dir as given in
the INSTALL_PREFIX.  It would be best (from Fedora's point of view) if
"make install" would respect such environment variables even if they
weren't set before build time.  I even tried re-running qmake before the
"make install" step (thinking that I could just have new Makefiles to do
the install on) but this did not work.  

--
"If you have only seen it once, then you haven't seen it twice."
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt@...
http://matt.truch.net/


_______________________________________________
Kst mailing list
Kst@...
https://mail.kde.org/mailman/listinfo/kst