Re: Conversion to /package

Paul Jarc <[email protected]> schrieb:
>Thomas Schwinge <[email protected]> wrote:
>> Another possibility I was thinking about was patching the programs that
>> make these software packages use the paths they use: the GNU auto*-suite.
>
>This is great.  I was planning on eventually talking to the auto*
>maintainers to try to convince them to add slashpackage capabilities,
>but a patch is better than a request.  Of course, they won't accept it
>if it means that auto* will no longer be useful for the traditional
>mode of operation.

Yes, that's true.
There are two reasons I didn't introduce a switch to ./configure to make
the package install in /package:
* I didn't need the "traditional" /usr/local paths anymore.
* I was so much easier that way... :-)

So it's really not praiseworthy what I've done:

#v+
--- autoconf-2.57/lib/autoconf/general.m4       2002-11-12 11:54:46.000000000 +0100
+++ autoconf-2.57-patched/lib/autoconf/general.m4       2003-08-30 21:29:50.000000000 +0200
@@ -442,7 +442,7 @@
 #
 # Initializations.
 #
-ac_default_prefix=/usr/local
+ac_default_prefix=/package/misc/spf/'${PACKAGE}-${VERSION}'
 ac_config_libobj_dir=.
 cross_compiling=no
 subdirs=
@@ -576,10 +576,10 @@
 # and all the variables that are supposed to be based on exec_prefix
 # by default will actually change.
 # Use braces instead of parens because sh, perl, etc. also accept them.
-AC_SUBST([bindir],         ['${exec_prefix}/bin'])dnl
-AC_SUBST([sbindir],        ['${exec_prefix}/sbin'])dnl
+AC_SUBST([bindir],         ['${exec_prefix}/command'])dnl
+AC_SUBST([sbindir],        ['${exec_prefix}/command'])dnl
 AC_SUBST([libexecdir],     ['${exec_prefix}/libexec'])dnl
-AC_SUBST([datadir],        ['${prefix}/share'])dnl
+AC_SUBST([datadir],        ['${prefix}/data'])dnl
 AC_SUBST([sysconfdir],     ['${prefix}/etc'])dnl
 AC_SUBST([sharedstatedir], ['${prefix}/com'])dnl
 AC_SUBST([localstatedir],  ['${prefix}/var'])dnl
@@ -987,10 +987,10 @@
 For better control, use the options below.
 
 Fine tuning of the installation directories:
-  --bindir=DIR           user executables [EPREFIX/bin]
-  --sbindir=DIR          system admin executables [EPREFIX/sbin]
+  --bindir=DIR           user executables [EPREFIX/command]
+  --sbindir=DIR          system admin executables [EPREFIX/command]
   --libexecdir=DIR       program executables [EPREFIX/libexec]
-  --datadir=DIR          read-only architecture-independent data [PREFIX/share]
+  --datadir=DIR          read-only architecture-independent data [PREFIX/data]
   --sysconfdir=DIR       read-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIR   modifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR    modifiable single-machine data [PREFIX/var]
--- autoconf-2.57/lib/autoconf/general.m4       2003-08-31 19:14:27.000000000 +0200
+++ autoconf-2.57-patched/lib/autoconf/general.m4       2003-08-31 19:12:27.000000000 +0200
@@ -478,7 +478,7 @@
 # AC_PREFIX_DEFAULT(PREFIX)
 # -------------------------
 AC_DEFUN([AC_PREFIX_DEFAULT],
-[m4_divert_text([DEFAULTS], [ac_default_prefix=$1])])
+[AC_MSG_WARN([Not changing the default prefix. Will use /package anyway.])])
 
 
 # AC_PREFIX_PROGRAM(PROGRAM)
@@ -491,16 +491,7 @@
 # and it might use a cached value for the path.
 # No big loss, I think, since most configures don't use this macro anyway.
 AC_DEFUN([AC_PREFIX_PROGRAM],
-[if test "x$prefix" = xNONE; then
-dnl We reimplement AC_MSG_CHECKING (mostly) to avoid the ... in the middle.
-  _AS_ECHO_N([checking for prefix by ])
-  AC_PATH_PROG(ac_prefix_program, [$1])
-  if test -n $ac_prefix_program; then
-    prefix=`AS_DIRNAME(["$ac_prefix_program"])`
-    prefix=`AS_DIRNAME(["$prefix"])`
-  fi
-fi
-])# AC_PREFIX_PROGRAM
+[AC_MSG_WARN([Not changing the default prefix. Will use /package anyway.])])
 
 
 # AC_CONFIG_SRCDIR([UNIQUE-FILE-IN-SOURCE-DIR])
#v-

Staying with strace that means:
configure.ac has a line
#v+
AC_INIT([strace],[4.4.98])
#v-
This will set AC_PACKAGE_TARNAME to strace and AC_PACKAGE_VERSION to
4.4.98.
These will be used to set PACKAGE and VERSION somewhere on the long way
going down through theses m4 scripts (aclocal.m4)...

I could also have used AC_PACKAGE_TARNAME and AC_PACKAGE_VERSION directly
while modifying ac_default_prefix, but I found out that older packages
had defined PACKAGE and VERSION instead of the AC_* ones.

AC_PREFIX_DEFAULT was taken out, because there were some packages that
used it in configure to get installed in /usr or something.
AC_PREFIX_PROGRAM purpouse was to find the current location of an
installed program, so that for example cvs would be installed as
/usr/bin/cvs if it had been installed as /usr/bin/cvs last time.

>But if there's a switch that can be used by a
>maintainer to produce either a traditional tarball or a slashpackage
>tarball, that'll make it much easier for more developers to start
>using slashpackage.

I can't follow you here:
Do you mean that the package's maintainer should decide if the package
will be installed in /package before it ist distributed or do you mean
that the user will be able to decide where to install via some
./configure switch (like Dan suggested)?

>> sp-links /package/misc/spf/strace/command /command &&
>
>I don't think that's a good path to use.  I've registered misc/spf/
>for my slashpackage-foreign project, for installing "foreign" packages
>in /package.

Yes, and that was also the reason for me to chose that path:
I wanted to install "foreign" packages in /package like you do with
sp-foreign.
I didn't want to create a new hierarchy for doing the same thing a
different way.

>Your work looks like it would be most useful to help
>more developers make "native" slashpackage releases (possibly in
>parallel with traditional releases).  Anyone slashpackaging their own
>software should register a name for it outside of misc/spf/.

This is exactly what I had in mind.
But since I'm not a maintainer of any package, my patches were only a
"proof of concept".

>> But the problem with this installation method is that there are too many
>> GNU packages out there that use and require too many different versions
>> of the GNU auto*-tools to let this method be practicable.
>
>It would definitely help for new development, though, which is
>certainly better than nothing.  I encourage you to bring this up on
>the relevant GNU lists (or I can, if you'd rather not stir up that
>hornet's nest) - gnu-misc-discuss, probably, along with autoconf,
>automake...  (libtool? autogen? which code did you have to change?)

I'm very sure that I'm not going to bring my patches up at the state
they are at current.
We should present something fully grown to them.

Regards,
 Thomas