chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Packaging eggs


From: Alaric Snell-Pym
Subject: Re: [Chicken-users] Packaging eggs
Date: Thu, 02 Sep 2010 08:38:05 +0100
User-agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.1.9) Gecko/20100520 Lightning/1.0b2pre Shredder/3.0.4

On 08/31/10 10:26, Felix wrote:
What's the official method for retrieving what non-scheme dependencies
the eggs have? I think I just had to determine this by trial and error
(sometimes reading the egg's documentation) and keep a record of it myself in 
the automation scripts. Is there no officially sanctioned way to mechanically 
retrieve this information?

No. This could be put into the .meta file, but we would have to specify a single
universal format usable over all supported platforms.

Yeah, not highly tractable.

However, it might be useful to put an "external-dependencies" key in the
meta file which has a list of... I dunno... human readable strings
saying "postgresql client libraries"? URLs of the main project pages of
the dependencies?

I've been asked by NetBSD users interested in packaging Ugarit as a
pkgsrc package if chicken-install could have an option to "extract" from
a previously-fetched henrietta-chunks file. pkgsrc has the following
sequence:

fetch (from a supplied URL, with fallback along a list if the first one
fails, eventually back to a netbsd.org central
mirror-of-almost-all-packages)
[pkgsrc then checks the checksums]
extract (into a directory tree)
patch (any NetBSD patches are applied)
build
install

The fetch/extract phases can be overridden somewhat, but it'd be nicer
to make use of the checksumming and mirroring infrastructure that's
already provided.

I'm not sure if chicken-install would let us separate build and install,
but at a pinch, build could be a no-op and install could do all the
work, I think.

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]