Re: [Vectorlinux-devel] Packaging Standards Redux

[John B <joh...@gm...>]

Guys,

The Tukaani pkgtools will allow us to build most packages as non-root users=
.
It passes --group=3Droot and --owner=3Droot to tar-1.13. Here are a couple =
of
links from the tukaani.org website:

ftp://tukaani.org/tukaani/tukaani-edge/source/tools/README - this file
explains how the tukaani tools work.

ftp://tukaani.org/tukaani/tukaani-edge/source/tools - it would be worth
checking out both the fakedestdir and tukbuild scripts. The fakedestdir
script will allow us to execute make install to a staging directory for
programs where make install DESTDIR=3D is not supported (unfortunately, the=
re
are enough of those around).

The tukbuild script is an interesting alternative to checkinstall and one
I've studied for a little bit. It appears to take the elements of
traditional SlackBuild scripts and standardizes a lot of build locations,
among other things, like including the stripping of unnecessary symbols fro=
m
the executables and shared libraries. (I like the standardization of instal=
l
locations in the tukbuild script - we could always modify it for our needs
as far as install locations go.) The way tukbuild works is you have a
program.tukbuild file. You invoke tukbuild and pass to it the
program.tukbuild file as a regular user. The tukbuild script then goes to
work based on the info in the program.tukbuild file. The tukbuild script
appears to be pretty well-commented so that even somebody with a limited
grasp of scripting, like me, can understand what is supposed to happen.

Below is the amarok.TukBuild file text to give you an idea of how this
system works, with my comments interspersed:

# set initial variables
NAME=3Damarok
VERSION=3D1.3.9
SOURCE=3Dhttp://dl.sf.net/amarok/amarok-$VERSION.tar.bz2 <--allows source t=
o
be downloaded if not already on box
BUILD=3D${BUILD:-1} <---set the build version; for us it would be #vl5 of #=
vl6
for the new version
# Trying to make it more stable, unsure if helps:
OPTIMIZE=3D${OPTIMIZE:-"-O1 -pipe"} <---FWIW, I've been able to build amaro=
k
with -O2, but then what do I know? ;-)
PREFIXTYPE=3Dkde <--- this macro tells the tukbuild script that we are
building a kde app and to use kde defaults

build() {
    _explode 0 <---this macro causes the tukbuild script to decompress the
tarball into a build directory
    cd amarok-$VERSION
    $CONFIGURE \ <---this macro invokes the ./configure script based on the
BUILD, OPTIMIZE and PREFIXTYPE set above - it also allows
application-specific settings to be passed, like the ones below
        --disable-debug \
        --disable-mysql \
        --enable-amazon \
        --without-gstreamer \
        --without-xmms
    make -j$MAKEJOBS <---the $MAKEJOBS variable is set in the main tukbuild
script based on the
    make DESTDIR=3D"$PKG" install
    _doc_except 0 amarok-$VERSION <---this macro creates the documentation
directory
    _chfix <---this macro will set the permissions to 0755 for executables
and 0644 for non-executables
    _chgrp_bin <---this macro will the owner and group for the executables
and directories to root.bin. Of course we could choose not to use it, since
I think it makes more sense for root.root to own the apps. ;-)
}

The tukbuild system may or may not be useful to us, but as I mentioned
above, I do like the fact that once you specify what type of building you'r=
e
doing, default locations are imposed (aka standards).

I hope y'all find this response useful.

Best,
John



On 4/8/06, Tony Brijeski <tb...@gm...> wrote:
>
> I agree with John and having standards.
>
> Ram - I don't think we should start allowing package installs all over th=
e
> place. This is asking for a huge headache.
>
>
>
> On 4/8/06, Sriram Durbha <sri...@gm...> wrote:
> >
> > you are right on the target john.it is much easier to support if we kno=
w
> > where all the files are going to be installed. and much better if they =
are
> > in a standard place for al packages.
> >
> > On a related note..  Most of the time i install to a local directory.  =
i
> > hate to pollute the root .
> > especially because it becomes difficult to uninstall if the package
> > doesnt have a good uninstall rule in the make file.
> >
> > One thing we can do to simplify things is allow installpkg to be run as
> > non root user also.
> >
> > If we are going to go the length,   shall we as well ask the user a
> > question like
> > " Install for all users or install for current user only ?" and proceed
> > appropriately to install in the user's $HOME or /
> >
> > The tree for the packge remains the sme but is located differently.
> > the local log of packages like in /var/log/packages .. will also have a
> > corresponding local version in $HOME
> >
> > To help this
> > we could have a list of packages and their options ..  something like
> > this ..
> > http://numsum.com/spreadsheet/show/17688
> > and create the ./configue  commands from that for all the packages for
> > the default install.
> >
> > cheers
> > ram
> >
> >
> >
> >
> > On 4/7/06, joh...@gm... < joh...@gm...> wrote:
> > >
> > > Some programs create their configuration files in an etc directory. I
> > > have
> > > seen some packages where such an etc directory was a subdirectory
> > > under /usr
> > > or /usr/X11R6. Since we are discussing standards for building package=
s
> > > with
> > > VL6, I believe that one of the arguments that should be passed to jus=
t
> > > about
> > > all configure scripts is --sysconfdir=3D/etc as opposed to letting th=
e
> > > sysconfdir setting default to a sub under --prefix=3D/usr.
> > >
> > > While I'm on this thread, some programs also create local data,
> > > notably dbus,
> > > hal, and samba, among others. I want to propose that we explicitly
> > > pass
> > > --localstatedir=3D/var to the configure script for such programs wher=
e
> > > local
> > > state data is created.
> > >
> > > Thoughts on these ideas, please.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > language
> > > that extends applications into web and mobile media. Attend the live
> > > webcast
> > > and join the prime developer group breaking into this new coding
> > > territory!
> > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&d=
at=3D121642
> > >
> > > _______________________________________________
> > > Vectorlinux-devel mailing list
> > > Vec...@li...
> > > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> > >
> >
> >
>