vectorlinux-devel

[Vectorlinux-devel] Packaging Standards Redux

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

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 packages with 
VL6, I believe that one of the arguments that should be passed to just about 
all configure scripts is --sysconfdir=/etc as opposed to letting the 
sysconfdir setting default to a sub under --prefix=/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=/var to the configure script for such programs where local 
state data is created.

Thoughts on these ideas, please.

Thanks,
John

Re: [Vectorlinux-devel] Packaging Standards Redux

[Sriram D. <sri...@gm...>]

you are right on the target john.it is much easier to support if we know
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 questio=
n
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 hav=
e
> seen some packages where such an etc directory was a subdirectory under
> /usr
> or /usr/X11R6. Since we are discussing standards for building packages
> with
> VL6, I believe that one of the arguments that should be passed to just
> about
> all configure scripts is --sysconfdir=3D/etc as opposed to letting the
> 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 where lo=
cal
> 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&dat=
=3D121642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>

Re: [Vectorlinux-devel] Packaging Standards Redux

[Tony B. <tb...@gm...>]

I agree with John and having standards.

Ram - I don't think we should start allowing package installs all over the
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 know
> where all the files are going to be installed. and much better if they ar=
e
> 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 doesn=
t
> 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 thi=
s
> ..
> http://numsum.com/spreadsheet/show/17688
> and create the ./configue  commands from that for all the packages for th=
e
> 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 packages
> > with
> > VL6, I believe that one of the arguments that should be passed to just
> > about
> > all configure scripts is --sysconfdir=3D/etc as opposed to letting the
> > 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 where
> > 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&dat=
=3D121642
> > _______________________________________________
> > Vectorlinux-devel mailing list
> > Vec...@li...
> > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> >
>
>

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

Re: [Vectorlinux-devel] Packaging Standards Redux

[Jose J. R. <jo...@gm...>]

On 4/8/06, joh...@gm... <joh...@gm...> wrote:
> Some programs create their configuration files in an etc directory. I hav=
e
> seen some packages where such an etc directory was a subdirectory under /=
usr
> or /usr/X11R6. Since we are discussing standards for building packages wi=
th
> VL6, I believe that one of the arguments that should be passed to just ab=
out
> all configure scripts is --sysconfdir=3D/etc as opposed to letting the
> sysconfdir setting default to a sub under --prefix=3D/usr.
>
> While I'm on this thread, some programs also create local data, notably d=
bus,
> hal, and samba, among others. I want to propose that we explicitly pass
> --localstatedir=3D/var to the configure script for such programs where lo=
cal
> state data is created.
>
> Thoughts on these ideas, please.
>

I agree on /var, since this is sometimes mounted on a separate
partition even. On /etc, I had my misgivings at first, thinking that
programs that install to /usr should use /usr/etc; but after careful
thought and checking out /usr/local/etc (found it empty), /usr/etc
(only sane.d, printcap and wgetrc) and /opt/kde/etc (only xdg and
ksysguarddrc), I realised that, at least the apps I've packaged, and
also any others I've installed, use /etc anyway. It has the added
advantage of making it easier to backup such info.

Regards,
Joe1962

Re: [Vectorlinux-devel] Packaging Standards Redux

[Sriram D. <sri...@gm...>]

i went thru the tukaani site earlier and in part my idea stems from theirs
:) [ installing as users ]
also i followed  a link from there to the LFS package idea page.. based on
package users.. i did not completely understand it..  but got the hang of
it. basically they want to install each package as a seperate user whose
username is same as the package name.
gives a lot of flexibility [ and its own share of headaches too.. ]

im sorry for introducing a different aspect without clearly identifying it.

1. stadnardization as per JohnB's initial post..  i couldnt agree more
2. installing as users ..  errr.. doesnt look like  its such a popular idea
so far.. so lets give it some rest for the time being maybe?


cheers
ram


On 4/8/06, Jose J. Rodriguez <jo...@gm...> wrote:
>
> On 4/8/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 packages
> with
> > VL6, I believe that one of the arguments that should be passed to just
> about
> > all configure scripts is --sysconfdir=3D/etc as opposed to letting the
> > 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 where
> local
> > state data is created.
> >
> > Thoughts on these ideas, please.
> >
>
> I agree on /var, since this is sometimes mounted on a separate
> partition even. On /etc, I had my misgivings at first, thinking that
> programs that install to /usr should use /usr/etc; but after careful
> thought and checking out /usr/local/etc (found it empty), /usr/etc
> (only sane.d, printcap and wgetrc) and /opt/kde/etc (only xdg and
> ksysguarddrc), I realised that, at least the apps I've packaged, and
> also any others I've installed, use /etc anyway. It has the added
> advantage of making it easier to backup such info.
>
> Regards,
> Joe1962
>
>
> -------------------------------------------------------
> 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?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>