Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 127463 - wm/stumpwm ebuild request
Summary: wm/stumpwm ebuild request
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Common Lisp Bugs
URL: http://www.gnu-rox.org
Whiteboard:
Keywords:
: 127465 127466 (view as bug list)
Depends on: 128288 128572 128920
Blocks:
  Show dependency tree
 
Reported: 2006-03-24 11:41 UTC by Xavier Maillard
Modified: 2006-04-06 09:15 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Ebuild proposition (stumpwm-cvs.ebuild,1.72 KB, application/octet-stream)
2006-03-24 11:53 UTC, Xavier Maillard
Details
New ebuild (stumpwm-cvs-0.ebuild,2.32 KB, text/plain)
2006-04-01 03:13 UTC, Xavier Maillard
Details
Updated ebuild (stumpwm-cvs-0.ebuild,2.15 KB, text/plain)
2006-04-02 10:16 UTC, Xavier Maillard
Details
Update ebuit with support for two new USE flags from clisp (stumpwm-cvs-0.ebuild,2.36 KB, text/plain)
2006-04-02 15:34 UTC, Xavier Maillard
Details
stumpwm-cvs-0.ebuild (stumpwm-cvs-0.ebuild,2.36 KB, text/plain)
2006-04-03 22:48 UTC, Xavier Maillard
Details
Updated ebuild (stumpwm-cvs-0.ebuild,2.40 KB, text/plain)
2006-04-04 15:01 UTC, Xavier Maillard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xavier Maillard 2006-03-24 11:41:16 UTC
Stumpwm is a tiling, keyboard driven X11 Window Manager written entirely in Common Lisp.

It is like ratpoison but in Common Lisp
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2006-03-24 11:45:09 UTC
*** Bug 127465 has been marked as a duplicate of this bug. ***
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2006-03-24 11:45:21 UTC
*** Bug 127466 has been marked as a duplicate of this bug. ***
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-03-24 11:49:29 UTC
*** Bug 127466 has been marked as a duplicate of this bug. ***
Comment 4 Xavier Maillard 2006-03-24 11:53:10 UTC
Created attachment 83034 [details]
Ebuild proposition

Enclosed is my contribution to see stumpwm into portage.
Comment 5 Xavier Maillard 2006-04-01 03:13:02 UTC
Created attachment 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
Comment 6 Xavier Maillard 2006-04-02 10:16:47 UTC
Created attachment 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.
Comment 7 Xavier Maillard 2006-04-02 15:34:45 UTC
Created attachment 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).
Comment 8 Xavier Maillard 2006-04-03 22:48:16 UTC
Created attachment 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)
Comment 9 Matthew Kennedy (RETIRED) gentoo-dev 2006-04-04 09:53:40 UTC
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
Comment 10 Matthew Kennedy (RETIRED) gentoo-dev 2006-04-04 09:53:40 UTC
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).
Comment 11 Xavier Maillard 2006-04-04 10:48:04 UTC
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.
Comment 12 Xavier Maillard 2006-04-04 15:01:49 UTC
Created attachment 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)
Comment 13 Xavier Maillard 2006-04-04 15:03:26 UTC
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
Comment 14 Xavier Maillard 2006-04-04 15:03:26 UTC
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

Comment 15 Xavier Maillard 2006-04-04 15:04:15 UTC
Did a wrong selection on previous Commit :/
Comment 16 Matthew Kennedy (RETIRED) gentoo-dev 2006-04-06 09:15:34 UTC
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.