1 |
On Mon, Oct 15, 2007 at 12:04:16PM +0200, Marijn Schouten (hkBst) wrote: |
2 |
>Stelian Ionescu wrote: |
3 |
>> On Sat, Oct 13, 2007 at 12:05:42PM +0200, Marijn Schouten (hkBst) wrote: |
4 |
>> [snip] |
5 |
>>>> I'll try to explain how CL packages work: |
6 |
>>>> |
7 |
>>>> 1) a CL package installs exactly one directory under |
8 |
>>>> /usr/share/common-lisp/source. This is contained in the variable |
9 |
>>>> $CLPACKAGE and it defaults to $PN. Exception: app-emacs/slime installs a |
10 |
>>>> package named "swank" |
11 |
>>> The code shows this is not really true. I couldn't find where a non-default |
12 |
>>> use was possible. You probably need to set: |
13 |
>>> |
14 |
>>> [[ CLPACKAGE == "" ]] && CLPACKAGE=${PN} |
15 |
>> |
16 |
>> there's no need for this construct because setting CLPACKAGE in the |
17 |
>> ebuild is only meant as an override of the default value |
18 |
> |
19 |
>I was thinking of having the variable set before inheriting the eclass, but if |
20 |
>you inherit first and set later it works as you intended. Please |
21 |
>comment that. |
22 |
|
23 |
Setting the variables before inheriting is useful if you want to use |
24 |
those variables as global parameters to the eclass, and the eclass does |
25 |
some computations based on those values at the moment of the inheriting; |
26 |
in this case I merely want to override a default set by the eclass. this |
27 |
allows me to have clean&little ebuilds with minimal stuff in it, |
28 |
i.e. which don't set any eclass variable and don't define src_install, |
29 |
because the defaults work. all for the sake of writing little code |
30 |
|
31 |
>>> or slime won't be able to install swank. |
32 |
>>> |
33 |
>>>> 2) a CL package contains one or more ASDF files(.asd). The variable |
34 |
>>>> $CLSYSTEMS contains the names of those systems and defaults to $PN |
35 |
>>>> because in the simplest case there is only one .asd |
36 |
>>>> The .asd files usually are contained in the toplevel of the source |
37 |
>>>> directory and get symlinked into /usr/share/common-lisp/systems |
38 |
>>> The code shows this is not really true. Therefore you cannot set $CLPACKAGE |
39 |
>>> and expect it to be used by common-lisp_src_install in its call to |
40 |
>>> common-lisp-system-symlink. Other eclasses use a construct like this: |
41 |
>>> |
42 |
>>> [[ CLSYSTEMS == "" ]] && CLSYSTEMS=${PN} |
43 |
>> |
44 |
>> same as before |
45 |
> |
46 |
>True. Why does common-lisp-system-symlink check for zero arguments? Is that |
47 |
>functionality needed by any ebuild? |
48 |
|
49 |
yes, most ebuilds don't need to specify explicitly the name of the .asd |
50 |
to install. common-lisp.eclass already has this thing and it worked well |
51 |
until now |
52 |
|
53 |
>>>> The eclass has three explicit "public" functions: |
54 |
>>>> |
55 |
>>>> 1) common-lisp-install(): must receive at least one argument. It installs |
56 |
>>>> files or directories(recursively) into /usr/share/common-lisp/source |
57 |
>>>> |
58 |
>>>> 2) common-lisp-system-symlink(): when called with no arguments, it |
59 |
>>>> installs the systems contained in $CLSYSTEMS. The system names must be |
60 |
>>>> relative paths. Example: CLSYSTEMS="foo1 foo2 src/bar" |
61 |
>>>> When called with some arguments, it installs those systems, ignoring |
62 |
>>>> $CLSYSTEMS |
63 |
>>> If I understand correctly the symlinks make it appear like CLPACKAGE contains |
64 |
>>> what CLSYSTEMS contains. What is the point of that or why does it need to be |
65 |
>>> that way? |
66 |
>> |
67 |
>> most CL packages contain precisely one .asd file, named exactly as the |
68 |
>> package; for example, kmrcl-1.97 contains only the kmrcl.asd system. |
69 |
>> Having CLPACKAGE=$PN and CLSYSTEMS=$PN is a good default |
70 |
> |
71 |
>That is not an answer. Why do we need to have two variables? Why can we not |
72 |
>collapse them into one? |
73 |
|
74 |
we always install all code provided by an upstream package in the same |
75 |
subdirectory of /usr/share/common-lisp/source, even if the tarball |
76 |
contains multiple ASD systems. for the ease of maintenance(or laziness |
77 |
if you like) I prefer to install code maintaining the exact tree it had |
78 |
in the tarball. this can be changed, of course, if we really want it |
79 |
only exception: cl-sql/clsql(new) |
80 |
|
81 |
>>>> 3) do-debian-credits(): taken from common-lisp-common.eclass, since I've |
82 |
>>>> dropped the inheritance on it |
83 |
>>> Which packages use this |
84 |
>> |
85 |
>> cl-aima, cl-irc, cl-sql, png, rt and split-sequence |
86 |
>> |
87 |
>>> and what's the point of doing it? |
88 |
>> |
89 |
>> as you know, many CL devs don't do releases(or not even versioning) so |
90 |
>> mkennedy thought well of using the snapshots made by Debian developers |
91 |
>> instead of making his own snapshots. It's meant as a way to credit |
92 |
>> Debian for this |
93 |
> |
94 |
>I don't know about many. A few yes. Having Debian oblige them certainly is a |
95 |
>mixed blessing. |
96 |
|
97 |
I don't think they're obliged by Debian, rather that Debian devs, |
98 |
noticing that the devs don't do releases, make snapshots on their own |
99 |
and use those |
100 |
|
101 |
> I don't think I like having code in our eclasss merely to give |
102 |
>credit and not nearly enough ebuilds seem to depend on this. Are any of the |
103 |
>installed files of practical use? |
104 |
|
105 |
I don't think so, I left do-debian-credits because mkennedy added |
106 |
it(probably because he thought it was a good thing) and I have nothing |
107 |
against it. Being this FOSS, I prefer to add credits rather than remove them |
108 |
|
109 |
-- |
110 |
Stelian Ionescu a.k.a. fe[nl]ix |
111 |
Quidquid latine dictum sit, altum videtur. |