[Openmcl-devel] A Debian packaging update and an outstanding issue
- Subject: [Openmcl-devel] A Debian packaging update and an outstanding issue
- From: email@example.com (Faheem Mitha)
- Date: Wed, 15 Aug 2012 09:17:11 +0530 (IST)
- Message-id: <[🔎] alpine.DEB.firstname.lastname@example.org>
- In-reply-to: <63C52CFA-BB92-4391-8754-01AFDD1EDD99@mailworks.org>
- References: <alpine.DEB.email@example.com> <63C52CFA-BB92-4391-8754-01AFDD1EDD99@mailworks.org>
Thank you for your response. Feedback from Debian Common Lisp team members
is always helpful. Copying pkg-common-lisp-devel at lists.alioth.debian.org
and Christoph Egger on this. See further comments below.
On Mon, 13 Aug 2012, Peter Van Eynde wrote:
> Hello all,
> [resend from correct account]
> On 13 Aug 2012, at 00:12, Faheem Mitha wrote:
>> CCL is not currently in Debian. Debian's archives only consists of
>> software compiled by Debian on Debian.
> For reference: CMUCL gets pushes as a binary+source with
> Build-Depends == version uploaded every time.
> So for a new version I upload a new source _and_ a new
> binary package every time.
> Now and again there are people opening bugs, but the real requirement is
> that you can recompile the distribution using programs in the
> distribution. As CMUCL version X can compile version X, just as CCL
> version X can compile version X there is no problem.
> SBCL version X can compile version Y so for that package
> there is no problem (TM).
> Except of course the tons of 'segfaults for me', 'uses too much
> memory' bugs which gets opened.
I looked at the Debian package of CMUCL 20c. and I see it build
depends on cmucl (>= 20c), and also that it does not contain any binary
files (as far as I can tell).
Can you give me more details of how your build process for initially
getting each version of CMUCL into Debian works? Do you download upstream
binaries and later discard them? Do you do something else?
In any case, the fact that CMUCL does not build depend on an earlier
version may make it easier for my CCL Debian package to pass inspection if
it turns out I do need to have CCL do something similar. However, one
question - ">= 20c" seems problematic, since how can you be sure a later
compiler will still be able to compile 2oc? Does upstream guarantee this?
> Best regards and good luck, Peter