[cl-debian] Re: [Bese-devel] YACLML: debianization
Hello! I'm sorry for the cross-posting, but the CL-Debian mailing-list is the best place about packaging CL software for Debian. Moreover, I'd like an advice from the Debian people involved in CL before finishing to package Marco's software. And I'm sorry for the long post O:-) On Thu 27 Oct 2005 10:39 +0200, Marco Baringer wrote:
Luca Capello <luca@pca.it> writes:
1) Referring to [1], YACLML *depends* on FiveAM if you want to use the test suite. So, if we want a single Debian package from YACLML, we need to depend on FiveAM. And AFAIK the same happens for the documentation, which needs qbook.
The other possibility is to have multiple Debian packages, if it's possible (I propend for this one):
cl-yaclml = all the strictly necessary files (depends on ASDF, arnesi and iterate, suggests cl-yaclml-test and cl-yaclml-doc) cl-yaclml-test = test suite (depends on cl-yaclml and FiveAM, suggests cl-yaclml-doc) cl-yaclml-doc = documentation (depends on cl-yaclml and qbook, suggests cl-yaclml-test)
is this a normal way of doing things? if so this is what i'd do.
While it's an usual thing to split a -doc package, I think that for the test suite there isn't a strict policy. Searching in the package archive gives the following. I sorted out the relevant packages ;-) ===== luca@gismo:~$ apt-cache search test atlas-test - Automatically Tuned Linear Algebra Software,test programs blacs-pvm-test - Basic Linear Algebra Comm. Subprograms - Test files for PVM blas-test - Basic Linear Algebra Subroutines, testing programs lapack-test - a library of linear algebra routines - testing programs lapack3-test - library of linear algebra routines 3 - testing programs refblas3-test - Basic Linear Algebra Subroutines 3, testing programs ultrapossum-test - UltraPossum SI Testing Framework xmldiff-test - xmldiff's test files blacs-lam-test - Basic Linear Algebra Comm. Subprograms - Test files for LAM blacs-mpich-test - Basic Linear Algebra Comm. Subprograms - Test files for MPICH blacs-test-common - Test data for BLACS testers cl-ansi-tests - Conformance tests for ANSI Common Lisp cl-uffi-tests - Regression tests for UFFI Common Lisp Library clamav-testfiles - use these files to test that your Antivirus program works ltp-commands-test - Command tests for the Linux Test Project ltp-disc-test - Disk I/O tests for the Linux Test Project ltp-kernel-test - kernel tests for the Linux Test Project ltp-misc-test - Misc. tests for the Linux Test Project ltp-network-test - Network tests for the Linux Test Project pylint-test - pylint's test files scalapack-lam-test - Scalable Linear Algebra Package - Test files for LAM scalapack-mpich-test - Scalable Linear Algebra Package - Test files for MPICH scalapack-pvm-test - Scalable Linear Algebra Package - Test files for PVM scalapack-test-common - Test data for ScaLAPACK testers typo3-testsite - A site package to show the abilities of TYPO3 zope-testcase - unit testing framework and test case for Zope parmetis-test - Parallel Graph Partitioning and Sparse Matrix Ordering Tests atlas3-test - Automatically Tuned Linear Algebra Software,test programs axiom-test - A general purpose computer algebra system: regression test inputs cl-sql-tests - Testing suite for CLSQL maxima-test - A fairly complete computer algebra system-- test suite php-simpletest - Unit testing and web testing framework for PHP sqlrelay-test - SQL Relay tests webauth-tests - Tests for the WebAuth authentication modules luca@gismo:~$ ===== Basically and AFAIK, we can decide whatever we want. Considering the space occupied by each package, we have (I just removed _darcs/ folder in each package): ===== luca@gismo:~/Hacking/cl-debian/repository$ du -h arnesi-test/ 16K arnesi-test/docs 68K arnesi-test/src/call-cc 312K arnesi-test/src 48K arnesi-test/t 396K arnesi-test/ luca@gismo:~/Hacking/cl-debian/repository$ du -h fiveam-test/ 68K fiveam-test/src 16K fiveam-test/t 104K fiveam-test/ luca@gismo:~/Hacking/cl-debian/repository$ du -h qbook-test/ 44K qbook-test/src 60K qbook-test/ luca@gismo:~/Hacking/cl-debian/repository$ du -h yaclml-test/ 24K yaclml-test/src/tags 64K yaclml-test/src/tal 128K yaclml-test/src 8.0K yaclml-test/t/root-a 12K yaclml-test/t/root-b 52K yaclml-test/t 196K yaclml-test/ luca@gismo:~/Hacking/cl-debian/repository$ ===== The simple solution will be to strictly depend on every software needed to *completely* use the package we're installing. So, YACLML should depends on ASDF/Common-Lisp-Controller, arnesi and iterate (to compile), plus FiveAM (for the test suite) and qbook (for the docs). This will lead to about 170K more space on disk (FiveAM and qbook), which is quite nothing :-) Obviously, if the dependencies for the /extra/ packages will grow in size (the test suite and the docs are not *strictly* necessary), we can split the package in the future. Now, reconsidering what I just wrote, I think that the simple solution is the best ATM. Suggestions? Peter, your opinion? Thx, bye, Gismo / Luca
Hi people, On Friday 28 October 2005 13:45, Luca Capello wrote:
[splitting packages] is this a normal way of doing things? if so this is what i'd do.
While it's an usual thing to split a -doc package, I think that for the test suite there isn't a strict policy
Well the policy gets involved because you should have a separate package if the architecture independent part (/usr/share/foo) gets 'too big'. This resulted in the splitting of sbcl into sbcl and sbcl-doc for example. Another reason to split a package is when a part is not always needed. For example slime is not slime (client) and cl-swank (server) parts because it is possible to run the swank on another machine then the client. Both cases do not seem to apply in this case: the lisp package is architecture independent by nature and the documentation is useless without the package. Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
Hello! On Fri 28 Oct 2005 22:20 +0200, Peter Van Eynde wrote:
On Friday 28 October 2005 13:45, Luca Capello wrote:
[splitting packages] is this a normal way of doing things? if so this is what i'd do.
While it's an usual thing to split a -doc package, I think that for the test suite there isn't a strict policy
Well the policy gets involved because you should have a separate package if the architecture independent part (/usr/share/foo) gets 'too big'. <cut> Another reason to split a package is when a part is not always needed. For example slime is not slime (client) and cl-swank (server) parts because it is possible to run the swank on another machine then the client.
Both cases do not seem to apply in this case: the lisp package is architecture independent by nature and the documentation is useless without the package.
Analyzing Marco's code and checking back the discussion Marco and I had when I first packaged YACLML, I now remember the problem (because there's a problem, sorry)... To read the documentation, you need qbook. To compile qbook, however, you need YACLML. This is the main reason I put qbook as a suggestion, because it's not *strictly* necessary, but it could be useful. And this situation applies to any other Marco's package: 1) arnesi compiles alone (without any other Marco's software) depends on FiveAM for :arnesi.test depends on cl-ppcre for :arnesi.cl-ppcre-extras depends on qbook for the docs 2) FiveAM compiles with arnesi depends on qbook for the docs 3) qbook compiles with arnesi, iterate, cl-ppcre and yaclml 4) YACLML compiles with arnesi and iterate depends on FiveAM for :yaclml.test depends on qbook for the docs Please someone corrects me if I forgot something. And my idea for the debianization: 1) arnesi depends on clc (in Debian this implies cl-asdf) recommends FiveAM, cl-ppcre and qbook 2) FiveAM depends on clc and arnesi recommends qbook 3) qbook depends on clc, arnesi, iterate, cl-ppcre and yaclml 4) YACLML depends on clc, arnesi and iterate recommends FiveAM and qbook Moreover, I can add on the package description (or in the README.Debian) why the recommendations, to advice the user of the other functionalities. Or, another solution which is straightforward, we don't have any Recommends/Suggests, but only Depends (cl-ppcre takes 100K and iterate 265K). BTW, the packages are ready, this is the last problem ;-) Thx, bye, Gismo / Luca
Hello! We're finally arrived to an end :-D On Sat 29 Oct 2005 13:23 +0200, Luca Capello wrote:
Analyzing Marco's code and checking back the discussion Marco and I had when I first packaged YACLML, I now remember the problem (because there's a problem, sorry)... <cut> And my idea for the debianization:
1) arnesi depends on clc (in Debian this implies cl-asdf) recommends FiveAM, cl-ppcre and qbook
2) FiveAM depends on clc and arnesi recommends qbook
3) qbook depends on clc, arnesi, iterate, cl-ppcre and yaclml
4) YACLML depends on clc, arnesi and iterate recommends FiveAM and qbook
Moreover, I can add on the package description (or in the README.Debian) why the recommendations, to advice the user of the other functionalities.
I found another package (not a CL package, sorry) that shares the same problem (inkscape) [1] [2] and I asked for advice on the Debian-devel mailing-list [3]. As I suspected, the Recommends field is the way to go. And there's no README.Debian explaining why :-D Here the cl-arnesi package description: ===== Package: cl-arnesi Architecture: all Depends: ${misc:Depends} Recommends: cl-ppcre, cl-fiveam, cl-qbook Description: small Common Lisp utilities arnesi is a Common Lisp utility suite. It contains various "bits 'n pieces" of code which were useful while developing other code. . Features: * Flow control macros - while, whichever, if-bind, etc. * A simple logging facility - kind-of/sort-of/maybe like log4j. * HTTP/HTML utilities - URL and HTML escaping * Pattern matching - fare-matcher style pattern matcher and "regular" list matcher * Accumulation - collecting and reducing macros * Cps transformer - an ad-hoc, bug ridden implementation of half of call/cc. * Decimal arithmetic - convert floats to exact rationals and vice versa with a given precision; standard rounding functions. * MOP compatibility package - The MOPP package provides the MOP's symbols on various implementations. Currently OpenMCL, CMUCL, SBCL, Lispworks and CLISP are supported. . The recommended packages add extra features: documentation via cl-qbook, test suite with cl-fiveam and add-ons for cl-ppcre. . This is the development version. ===== If I'm not getting any negative feedback for tomorrow (Friday 3th) 00:00 UTC, I'll start submitting ITP for arnesi, FiveAM, qbook and YACLML using that backbones. Thx, bye, Gismo / Luca [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=317767 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328423 [3] http://lists.debian.org/debian-devel/2005/11/msg00066.html
participants (2)
-
Luca Capello -
Peter Van Eynde