Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Stumpwm is a tiling, keyboard driven X11 Window Manager written entirely in
Common Lisp.

It is like ratpoison but in Common Lisp

*** Bug 127465 has been marked as a duplicate of this bug. ***

*** Bug 127466 has been marked as a duplicate of this bug. ***

*** Bug 127466 has been marked as a duplicate of this bug. ***

Created an attachment (id=83034) [details]
Ebuild proposition

Enclosed is my contribution to see stumpwm into portage.

Created an attachment (id=83601) [details]
New ebuild

This is my new ebuild which now:

- check for X USE flag when clisp USE flag is used
- add cl-clx has sbcl USE flag dependance
- die when clisp USE flag is used (see bug 128288 for details)

Voila

Created an attachment (id=83727) [details]
Updated ebuild

Take into account the evolution on bug 128288 (die if clisp had not been built
with X USE flag plus throw a warning concerning x11-misc/imake dependancy).

Tested and fully working.

Created an attachment (id=83773) [details]
Update ebuit with support for two new USE flags from clisp

This ebuild contains the needed modifications called on bug 128573 (deletion of
X USE flag and creation of mit-clx and new-clx USE flags).

This ebuild does the check for either mit-clx and new-clx and die if none have
been USED or warn if new-clx has been used (stumpwm is not yet stabilized with
the new-clx module).

Created an attachment (id=83860) [details]
stumpwm-cvs-0.ebuild

Ebuild modified to work with clisp-2.38-r2 (X and new-clx USE flags support and
dependency on clisp-2.38-r2)

OK. Now that those blockers are out of the way we can work on
x11-wm/stumpwm-cvs.  I looked at your ebuild and have some comments and
suggestions.  I wouldn't normally respond in such detail except you have
aspirations to help the Common Lisp/Emacs teams as a future developer and I
think this a good opportunity to talk about ebuild design.

Firstly, the top two lines read:

    # Ebuild by Xavier Maillard (zedek@gnu.org)
    # This is released under the GNU GPL v2 and later

Due to Gentoo development policies, mostly documented at
http://www.gentoo.org/proj/en/devrel/copyright/index.xml, I can't commit that
ebuild as-is.  It needs to appear as:

    # Copyright 1999-2006 Gentoo Foundation
    # Distributed under the terms of the GNU General Public License v2
    # $Header: $

All ebuilds and other gentoo project code have to have the same copyright owner
so that it can be defended legally as a single identity.  You can find out more
about the Gentoo Foundation here: http://www.gentoo.org/foundation/en/.  

Secondly, early on in Gentoo's development, it was decided to license under the
"GNU General Public License v2", not the "GNU General Public License v2 or
later".  I forget the rationale behind that decision and (IMO) its too bad we
won't get GPL3's new protections automatically.

The DEPEND list looks like this:

RDEPEND="${DEPEND}
        || ( dev-lisp/common-lisp-controller virtual/commonlisp )
            dev-lisp/cl-asdf
        emacs? ( virtual/emacs || ( app-emacs/slime app-emacs/slime-cvs ))
        || ( x11-base/xorg-x11 virtual/x11 )
        !clisp? ( !sbcl? ( dev-lisp/cmucl ))
        clisp? ( >=dev-lisp/clisp-2.38-r2 )
        sbcl?  ( >=dev-lisp/sbcl-0.8.14 dev-lisp/cl-clx )"

I think we should move the following to DEPEND:

   dev-lisp/common-lisp-controller
   virtual/commonlisp

I know this is a bit screwy, because nothing gets built until runtime when the
user issues "(asdf:oos 'asdf:load-op :stumpwm)", but all the Common Lisp
ebuilds have that pair of deps in DEPEND, so best to be consistent with them. 
Why are things this way?  Well that's because historically CLC-3.x did actually
build Common Lisp code at emerge time.  Of course, the more lispy CLC-4.x and
CLC-5.x don't.  Maybe we should change the dependencies tree-wide for Common
Lisp ebuilds to RDEPEND sometime...

dev-lisp/common-lisp-controller depends on dev-lisp/cl-asdf, so we can omit
dev-lisp/cl-asdf from stumpwm's DEPEND list.

Because CLX is a stream-level X11 library, it doesn't really need any part of
Xorg/XFree86/someotherXsystem.  This is true of dev-lisp/cl-clx, cmucl's own
CLX and also CLISP's MIT-CLX (actually all of those are derived from the
original MIT CLX implementation).  CLISP's NEW-CLX is a C binding to
Xorg/XFree86 libraries and would depend on said C libraries.  Therefore, since
we're using stream-level CLX libraries only, we can omit the following line:

        || ( x11-base/xorg-x11 virtual/x11 )

I believe the emacs dependency line is correct:

        emacs? ( virtual/emacs || ( app-emacs/slime app-emacs/slime-cvs ))

I think stumpwm really benifits from SLIME.  So covering that with the emacs
USE flag makes sense.  app-emacs/slime and app-emacs/slime-cvs both depend on
virtual/emacs though, so virtual/emacs can be removed from that line.

The remaining dependencies look acceptable to me.  I think maxima in portage
has a similar stategy.

        !clisp? ( !sbcl? ( dev-lisp/cmucl ))
        clisp? ( >=dev-lisp/clisp-2.38-r2 )
        sbcl?  ( >=dev-lisp/sbcl-0.8.14 dev-lisp/cl-clx )"

I think they way you're written pkg_setup looks good.

On the following line, the doinfo needs to be condition on "use doc":

        doinfo stumpwm.info || die "doinfo failed"
ie.
        use doc && doinfo stumpwm.info

In your pkg_postinst():

pkg_postinst() {
        while read line; do einfo "${line}"; done <${FILESDIR}/README.Gentoo
        einfo "Please consult the NEWS file to know what have changed since
latest emerging."
        if use emacs; then
           einfo "You can interact with the REPL by typing this: "
           einfo "(require 'swank)"
           einfo "(swank:create-swank-server 4005 :spawn)"
        fi

}

We need to add a call to common-lisp_pkg_postinst (from the inherited
common-lisp.eclass).  For that to work though, we need to set CLPACKAGE at the
top of the ebuild (which you've already done) to the name of the Common Lisp
system definition -- ie. "stumpwm" in stumpwm's case (the .asd filename sans
extension).

The comment about checking the NEWS file is a good idea.  I wonder though, in
an upgrade, we'll see the already installed NEWS file from src_unpack and also
be able to see the new one just pulled from CVS.  Perhaps we can take the diff
of them and install that to /usr/share/doc/${PF}/NEWS.diff and direct the user
there.  Sounds like a handy thing to have for any CVS ebuild...

In pkg_postinst you referenced a "README.Gentoo" file which I dont think you
have attached to this bug report.  I suppose it contains hints on creating a
script to invoke stumpwm from all this Common Lisp/ASDF complexity ;-)  What
did you have in mind for README.Gentoo?  Also, if you display it from
pkg_postinst, you may as well install it with dodoc in src_install so the user
can revisit it later.

As for invoking StumpWM in a uniform way for all the Common Lisp
implementations we're supporting (CLISP, SBCL, CMUCL) we might want to check
out dev-lisp/cl-launch which is a very good, portable script generator and
implementation launcher written by Far

OK. Now that those blockers are out of the way we can work on
x11-wm/stumpwm-cvs.  I looked at your ebuild and have some comments and
suggestions.  I wouldn't normally respond in such detail except you have
aspirations to help the Common Lisp/Emacs teams as a future developer and I
think this a good opportunity to talk about ebuild design.

Firstly, the top two lines read:

    # Ebuild by Xavier Maillard (zedek@gnu.org)
    # This is released under the GNU GPL v2 and later

Due to Gentoo development policies, mostly documented at
http://www.gentoo.org/proj/en/devrel/copyright/index.xml, I can't commit that
ebuild as-is.  It needs to appear as:

    # Copyright 1999-2006 Gentoo Foundation
    # Distributed under the terms of the GNU General Public License v2
    # $Header: $

All ebuilds and other gentoo project code have to have the same copyright owner
so that it can be defended legally as a single identity.  You can find out more
about the Gentoo Foundation here: http://www.gentoo.org/foundation/en/.  

Secondly, early on in Gentoo's development, it was decided to license under the
"GNU General Public License v2", not the "GNU General Public License v2 or
later".  I forget the rationale behind that decision and (IMO) its too bad we
won't get GPL3's new protections automatically.

The DEPEND list looks like this:

RDEPEND="${DEPEND}
        || ( dev-lisp/common-lisp-controller virtual/commonlisp )
            dev-lisp/cl-asdf
        emacs? ( virtual/emacs || ( app-emacs/slime app-emacs/slime-cvs ))
        || ( x11-base/xorg-x11 virtual/x11 )
        !clisp? ( !sbcl? ( dev-lisp/cmucl ))
        clisp? ( >=dev-lisp/clisp-2.38-r2 )
        sbcl?  ( >=dev-lisp/sbcl-0.8.14 dev-lisp/cl-clx )"

I think we should move the following to DEPEND:

   dev-lisp/common-lisp-controller
   virtual/commonlisp

I know this is a bit screwy, because nothing gets built until runtime when the
user issues "(asdf:oos 'asdf:load-op :stumpwm)", but all the Common Lisp
ebuilds have that pair of deps in DEPEND, so best to be consistent with them. 
Why are things this way?  Well that's because historically CLC-3.x did actually
build Common Lisp code at emerge time.  Of course, the more lispy CLC-4.x and
CLC-5.x don't.  Maybe we should change the dependencies tree-wide for Common
Lisp ebuilds to RDEPEND sometime...

dev-lisp/common-lisp-controller depends on dev-lisp/cl-asdf, so we can omit
dev-lisp/cl-asdf from stumpwm's DEPEND list.

Because CLX is a stream-level X11 library, it doesn't really need any part of
Xorg/XFree86/someotherXsystem.  This is true of dev-lisp/cl-clx, cmucl's own
CLX and also CLISP's MIT-CLX (actually all of those are derived from the
original MIT CLX implementation).  CLISP's NEW-CLX is a C binding to
Xorg/XFree86 libraries and would depend on said C libraries.  Therefore, since
we're using stream-level CLX libraries only, we can omit the following line:

        || ( x11-base/xorg-x11 virtual/x11 )

I believe the emacs dependency line is correct:

        emacs? ( virtual/emacs || ( app-emacs/slime app-emacs/slime-cvs ))

I think stumpwm really benifits from SLIME.  So covering that with the emacs
USE flag makes sense.  app-emacs/slime and app-emacs/slime-cvs both depend on
virtual/emacs though, so virtual/emacs can be removed from that line.

The remaining dependencies look acceptable to me.  I think maxima in portage
has a similar stategy.

        !clisp? ( !sbcl? ( dev-lisp/cmucl ))
        clisp? ( >=dev-lisp/clisp-2.38-r2 )
        sbcl?  ( >=dev-lisp/sbcl-0.8.14 dev-lisp/cl-clx )"

I think they way you're written pkg_setup looks good.

On the following line, the doinfo needs to be condition on "use doc":

        doinfo stumpwm.info || die "doinfo failed"
ie.
        use doc && doinfo stumpwm.info

In your pkg_postinst():

pkg_postinst() {
        while read line; do einfo "${line}"; done <${FILESDIR}/README.Gentoo
        einfo "Please consult the NEWS file to know what have changed since
latest emerging."
        if use emacs; then
           einfo "You can interact with the REPL by typing this: "
           einfo "(require 'swank)"
           einfo "(swank:create-swank-server 4005 :spawn)"
        fi

}

We need to add a call to common-lisp_pkg_postinst (from the inherited
common-lisp.eclass).  For that to work though, we need to set CLPACKAGE at the
top of the ebuild (which you've already done) to the name of the Common Lisp
system definition -- ie. "stumpwm" in stumpwm's case (the .asd filename sans
extension).

The comment about checking the NEWS file is a good idea.  I wonder though, in
an upgrade, we'll see the already installed NEWS file from src_unpack and also
be able to see the new one just pulled from CVS.  Perhaps we can take the diff
of them and install that to /usr/share/doc/${PF}/NEWS.diff and direct the user
there.  Sounds like a handy thing to have for any CVS ebuild...

In pkg_postinst you referenced a "README.Gentoo" file which I dont think you
have attached to this bug report.  I suppose it contains hints on creating a
script to invoke stumpwm from all this Common Lisp/ASDF complexity ;-)  What
did you have in mind for README.Gentoo?  Also, if you display it from
pkg_postinst, you may as well install it with dodoc in src_install so the user
can revisit it later.

As for invoking StumpWM in a uniform way for all the Common Lisp
implementations we're supporting (CLISP, SBCL, CMUCL) we might want to check
out dev-lisp/cl-launch which is a very good, portable script generator and
implementation launcher written by Faré Rideau (see
http://www.cliki.net/cl-launch).

This is really a great explanation you gave here, I have learnt many new things
and your course on dependencies is just wonderful :)

As for the cl-launch utilisation, I do not have any opinion about that since I
do not know it.

I will try to submit a new ebuild file with your modifications applied.

Created an attachment (id=83919) [details]
Updated ebuild

New ebuild following Matthew recommendations:

1. updated copyright ala gentoo
2. removed useless dependances
3. added call to common-lisp_pkg_postinst
4. doinfo if doc USE flag

(I removed einfo in postint since it needs more work to document things
correctly)

Note that calling common-lisp_pkg_postint returns this:

>>> Original instance of package unmerged safely.
 * Registering Common Lisp source for stumpwm
/usr/sbin/register-common-lisp-source: line 7:
/usr/sbin/clc-update-customized-images: Aucun fichier ou r

Note that calling common-lisp_pkg_postint returns this:

>>> Original instance of package unmerged safely.
 * Registering Common Lisp source for stumpwm
/usr/sbin/register-common-lisp-source: line 7:
/usr/sbin/clc-update-customized-images: Aucun fichier ou répertoire de ce type

Did a wrong selection on previous Commit :/

Thanks.  I fixed the CLC problem and commited stumpwm-cvs to portage.  I
changed the ebuild a little and added a README.Gentoo to the install.  Its
goals are to warn users about CVS ebuilds and provide some hints on getting
started with Stumpwm.