[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: /package support
From: |
Stefan Karrmann |
Subject: |
Re: /package support |
Date: |
Mon, 10 Feb 2003 22:01:11 +0100 |
User-agent: |
Mutt/1.3.27i |
Paul Eggert (Fri, Dec 13, 2002 at 01:05:32AM -0800):
> > Date: Thu, 12 Dec 2002 19:49:08 +0100
> > From: Stefan Karrmann <address@hidden>
> > User-Agent: Mutt/1.3.27i
> >
> > Does autoconf support /package (see http://cr.yp.to/slashpackage.html)?
>
> That depend on what you mean by "support". It doesn't prohibit
> /package, but it doesn't go out of its way to help either.
If autoconf supports /package then
./configure --slash-package=/
should search in /package (or /command) for packages like sh,
fileutils, etc. Moreover, it should install the current package into
/package/this/package/s/global/category/package-version.
> Suppose, for example, that an Autoconf-generated "configure" finds a
> package on the installer's machine at compile-time, which is not
> available on the run-time machine, and is not explicitly listed as a
> run-time dependency. The program won't work. Is that Autoconf's
> fault? Should Autoconf help out on this? As far as I know, nobody
> has really thought about these issues. Someone who likes /package
> will have to volunteer to do the hard slogging, I'm afraid.
In /package you can simply list the packages (with version number)
that exist on the run-time machine. Then autoconf should know the
run-time date (shared libs, commands, etc.) while it can read the
static libs, etc. on the compile-time machine.
Ralf Corsepius (Fri, Dec 13, 2002 at 10:19:49AM +0100):
> Am Don, 2002-12-12 um 19.49 schrieb Stefan Karrmann:
> > Does autoconf support /package (see http://cr.yp.to/slashpackage.html)?
> No, because package-management is not one of autoconf's task.
Thats right, but see below.
> (It neither supports rpm, deb, slack or what ever package-management
> systems people might have brought up).
Well, /package is not a only package-management system, but defines
unique global names where autoconf could find packages/libs/includes etc.
>
> > The /package design separates packages cleanly, such that even the
> > need of a package manager is small. It would be nice if autoconf
> > supports it, since then a lot of packages come into /package.
Cheers,
--
Stefan Karrmann
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: /package support,
Stefan Karrmann <=