On 23 Jan 2001, Tom Tromey wrote:
> [...]
> This is an attractive idea, but it doesn't work if you also want to
> extract the post/pre-install/uninstall commands automatically. And
> you definitely do want to do this because sometimes these are hairy
> scripts generated by automake itself.
>
>
Ganesan Rajagopal wrote:
> ...
> You normally *have* to package only installed binaries, especially
> with libtool libraries.
Don't get me started about libtool... :)
Actually, now that libtool has pretty much stablized you can just
reference the files under the .libs directory, although I've be
> "Michael" == Michael Sweet <[EMAIL PROTECTED]> writes:
> Alexandre Oliva wrote:
>>
>> On Jan 22, 2001, Michael Sweet <[EMAIL PROTECTED]> wrote:
>>
>> > What it doesn't do (yet) is provide a tool to automate the creation
>> > of the list file.
>>
>> make install DESTDIR=/tmp/install
>> fi
Alexandre Oliva wrote:
>
> On Jan 22, 2001, Michael Sweet <[EMAIL PROTECTED]> wrote:
>
> > What it doesn't do (yet) is provide a tool to automate the creation
> > of the list file.
>
> make install DESTDIR=/tmp/install
> find /tmp/install/. ! -name . -print | sed 's,^/tmp/install,,'
> rm -rf /t
Geoffrey Wossum wrote:
>
> > Actually, you could probably steal the script stuff from the
> > portable.c file that shows the license agreement. I wouldn't wait
> > for the response (that would break GUI installers), but at least
> > you can cat out the license agreement to the screen...
>
> But
On Jan 22, 2001, Michael Sweet <[EMAIL PROTECTED]> wrote:
> What it doesn't do (yet) is provide a tool to automate the creation
> of the list file.
make install DESTDIR=/tmp/install
find /tmp/install/. ! -name . -print | sed 's,^/tmp/install,,'
rm -rf /tmp/install
--
Alexandre Oliva Enjoy Gu
Tom Tromey wrote:
> ...
> Michael>The downside is that you have to somehow clear the
> Michael>existing list file before doing this, or only do it
> Michael>once, so that you have the correct set of files...
>
> I don't understand this.
Basically, the install-sh hack woul
> Actually, you could probably steal the script stuff from the
> portable.c file that shows the license agreement. I wouldn't wait
> for the response (that would break GUI installers), but at least
> you can cat out the license agreement to the screen...
But just displaying the license doesn't h
> "Michael" == Michael Sweet <[EMAIL PROTECTED]> writes:
Michael> http://www.easysw.com/epm
I haven't tried this, but I read through the web site, and it
definitely looks like what I'd like out of an `autopackage'.
Michael> 1. Provide an install-sh like script that appends the
Micha
On Mon, Jan 22, 2001 at 09:49:04PM -0500, Michael Sweet wrote:
> Rusty Ballinger wrote:
> > ...
> > (What packaging systems only let you create packages as root, and
> > why do they do that? I know rpm *wants* you to be root, but you
> > don't have to be...)
>
> Debian's dpkg needs you to run as
"Derek R. Price" wrote:
> ...
> Due to security concerns, you're obviously never going to be able
> to install files owned by root without root privledges, but are
> you really telling me that these systems require you to _build_
> packages as root?
For all practical purposes, yes.
For Debian, t
Geoffrey Wossum wrote:
> ...
> the job right now. For instance, our packages are supposed to
> have a pre-install script that does a click-through agreement.
> I've tried to explain that you can tell the package system (rpm,
> at least) not to run pre-install scripts and therefore it probably
> w
> > Are there several issues here?
> >
> > The package maintainer has the package to worry about.
>
> Aha! Here's the crossed wire. What I was envisioning was a package tool
> designed such that most platforms wouldn't _need_ devoted package
> maintainers .
We're using different language. For
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
> Due to security concerns, you're obviously never going to be able to
> install files owned by root without root privledges, but are you really
> telling me that these systems require you to _build_ packages as root?
Yes, this is normal
Michael Sweet wrote:
> Rusty Ballinger wrote:
> > ...
> > (What packaging systems only let you create packages as root, and
> > why do they do that? I know rpm *wants* you to be root, but you
> > don't have to be...)
>
> Debian's dpkg needs you to run as root; otherwise the files you
> install w
Harlan Stenn wrote:
> Are there several issues here?
>
> The package maintainer has the package to worry about.
Aha! Here's the crossed wire. What I was envisioning was a package tool
designed such that most platforms wouldn't _need_ devoted package maintainers.
A single package maintainer usi
> I'm getting into this discussion a little late, but here are my
> $0.02.
>
> First, see:
>
> http://www.easysw.com/epm
>
> and specifically:
>
> http://www.easysw.com/epm/epm-paper.html
Yes, actually I have looked at it. I'm using it to build the packages in
my project right now.
Rusty Ballinger wrote:
> ...
> (What packaging systems only let you create packages as root, and
> why do they do that? I know rpm *wants* you to be root, but you
> don't have to be...)
Debian's dpkg needs you to run as root; otherwise the files you
install will be owned by your user & group.
H
> > This module may be very valuable for you if you want to create packages
> > not as root. GNU tar cannot be tricked into hardcoding the ownership
> > different from the actual ones (as far as I know).
>
> You can use 'fakeroot' (now called 'libtricks' I think) from Debian.
> It is essentially a
Pavel Roskin wrote:
> ...
> not as root. GNU tar cannot be tricked into hardcoding the ownership
> different from the actual ones (as far as I know).
> ...
Also, you can't map the filenames/directories, e.g.:
filename.c -> project-major.minor/filename.c
program -> /usr/bin/program
--
_
Hi,
Pavel Roskin <[EMAIL PROTECTED]> writes:
[snip]
> This module may be very valuable for you if you want to create packages
> not as root. GNU tar cannot be tricked into hardcoding the ownership
> different from the actual ones (as far as I know).
You can use 'fakeroot' (now called 'libtricks'
Hello, Geoffrey!
> Anyway, here's some of my thoughts about it:
> 1) written in Python
In case you ever change you mind, there is an implementation of tar
written entirely in Perl:
http://www.cpan.org/modules/by-module/Archive/
This module may be very valuable for you if you want to create pac
Are there several issues here?
The package maintainer has the package to worry about.
Another "hat" might wrap packages for installers, including templates for a
variety of sources (like RPMs, the FreeBSD ports collection, etc).
The last "hat" would take these packages, possibly build them, and
"Derek R. Price" wrote:
> ...
> I'm still thinking a two stage process is in order: A script that
> scrapes the Makefile and a meta spec file (since the make process
> is invoking it this could simply mean it is passed the appropriate
> data) to create the package manager specific spec file and a
Geoffrey Wossum wrote:
> > You can use GNU m4 or PERL in autoconf and automake, as these are
> > maintainer-only tools. If autopackage is a package-installer tool (i.e. a
> > native package front-end) the choice of implementation language is almost
> > restricted to "/bin/sh" or "/bin/sh" and pro
> I think this need to depend on the configure-generated Makefile will have a
> very constraining effect on the implementation language: this precludes
> using ANYTHING that's not installed standard on any of the expected target
> OSes... That's exactly why configure generates sh-scripts and why l
> -Original Message-
> From: Derek R. Price [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 19, 2001 10:36 PM
> To: [EMAIL PROTECTED]
> Cc: Geoffrey Wossum; [EMAIL PROTECTED]
> Subject: Re: More an autopackage
>
>
> Tom Tromey wrote:
>
> > Unf
I think "layers" of config.site would be useful for parts of autopackage.
There are other a number of packages out there that attempt to solve this
problem in different ways, with varying degrees of success.
One set of extremes is the GNU stow project v. the Modules project.
Lately I'm playing
Tom Tromey wrote:
> Unfortunately, I don't think it is that easy.
>
> First, Makefile.am contents can be conditional on the particular
> configuration. That is why you really want to deal with the
> post-configuration package (using `make') and not Makefile.am.
>
> Second, the more complex post-
Geoffrey Wossum wrote:
> I was thinking about this, and I considered another possibility. autopkg
> would scan the Makefile.am to build a basic specfile, which the developer
> could then add pre/post install scripts and so forth. This would be
> analogous to autoscan producing a basic configure
> "Geoffrey" == Geoffrey Wossum <[EMAIL PROTECTED]> writes:
Geoffrey> I was thinking about this, and I considered another
Geoffrey> possibility. autopkg would scan the Makefile.am to build a
Geoffrey> basic specfile, which the developer could then add pre/post
Geoffrey> install scripts and s
> Automake can't create all of the spec file. It doesn't have enough
> information. And, adding the information to Makefile.am does not make
> sense (because it is global to a package, which Makefile.am really
> isn't).
>
> Also, generating a list of files is not enough. You also need pre-
> a
Has anybody looked at (epm) Easy Package Manager (http://www.easysw.com/epm/?
>From the FAQ:
--
It is a simple tool that generates software and patch distributions in
various formats, including:
AT&T Software Packages ("pkg"), used by Solaris.
Debian Package Manager ("dpkg")
HP-UX Software Pac
> "Geoffrey" == Geoffrey Wossum <[EMAIL PROTECTED]> writes:
Geoffrey> Anyway, here's some of my thoughts about it:
Geoffrey> 1) written in Python
The required language flame war has already started. However I think
the implementation language is the least important thing. The
important th
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> Aren't we supposed to use GNU guile for all FSF-supported
Bob> script-based tools? In fact, isn't Automake itself intended to be
Bob> eventually re-written in guile?
Yes, that is the intent. I doubt I'll be doing the work though.
On Thu, 18 Jan 2001, Geoffrey Wossum wrote:
> > > Anyway, here's some of my thoughts about it:
> > > 1) written in Python
> >
> > Wouldn't Perl5 be a more widely acceptable choice? Considerably so?
> > (Indeed, isn't automake already in Perl? Why choose something different?
> > Especially w
> > Anyway, here's some of my thoughts about it:
> > 1) written in Python
>
> Wouldn't Perl5 be a more widely acceptable choice? Considerably so?
> (Indeed, isn't automake already in Perl? Why choose something different?
> Especially when that something is considerably less widely installed?
> > Wouldn't Perl5 be a more widely acceptable choice? Considerably so?
> > (Indeed, isn't automake already in Perl? Why choose something different?
> > Especially when that something is considerably less widely installed?)
>
> Because Perl is almost unreadable and Python is a very nice language
On Jan 18, 2001, David Lee <[EMAIL PROTECTED]> wrote:
> On Thu, 18 Jan 2001, Geoffrey Wossum wrote:
>> 1) written in Python
> Wouldn't Perl5 be a more widely acceptable choice? Considerably so?
> (Indeed, isn't automake already in Perl? Why choose something different?
> Especially when tha
On Thu, 18 Jan 2001, Geoffrey Wossum wrote:
> I want to work on the unified front-end to native packaging systems like I
> posted before, but the bossman doesn't want to wait until that's useable.
> So the autopackage front-end is going to be YASP (yet another side
> project) for me.
>
> Anyway,
Hi again,
I want to work on the unified front-end to native packaging systems like I
posted before, but the bossman doesn't want to wait until that's useable.
So the autopackage front-end is going to be YASP (yet another side
project) for me.
Anyway, here's some of my thoughts about it:
1) writt
41 matches
Mail list logo
