a couple of vn-cclan package procedure questions

Miles Egan <[email protected]>
Newsgroups gmane.lisp.cclan.general
Message-ID <[email protected]>
I've been messing around with asdf and some vn-cclan packages and I've
come up with a few questions.

1. Should we assimilate parts of clocc?
Clocc as a whole seems pretty fundamentally incompatible with
vn-cclan, although there are modular bits of it that might be nice to
have.  I've wrapped Paul Graham's "On Lisp" utilities as an asdf
package and they stand alone pretty nicely.  They're also not likely
to change much so it's not too worrisome that this will in effect
become a fork.  Other pieces are more interdependent though, and
pulling them out and making them work in vn-cclan might amount to a
fork.  Any thoughts?  Rewrite this stuff?  Fork?  Build tools that can
build asdf packages from a clocc snapshot?

2. How should vn-cclan packages be named?
There's already a couple of conventions in play in the current
repository.  I'm not a big fan of the domain-style names (com.foo.bar)
because they emphasize an ephemeral and non-descriptive property of
the package.  CPAN seems to have gotten along great without them.
Prefixing the packages with CL seems silly too since they'll all be
common lisp.  Doing nothing to change the name of the package makes it
hard to tell the original source distrubution apart from the asdf
package (the names would be the same in most cases).  Is it too cheesy
to give the packages simple but descriptive names and add an asd
prefix or suffix, so that, for example:

net-telent-date-1.0 -> asd-date-1.0.tar.gz or date-1.0.asd

?

I'm not sure what the right answer is here.

-- 
miles egan
[email protected]

OpenPGP/GPG Key 0x01F53D51 @ wwwkeys.us.pgp.net
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9EM+NU4Jq/wH1PVERAj99AKCnHTGvN3/BfmdsJqf42uL6MW3gfQCgxm78
Q7ioxasLppRMi6eFrlL9LMA=
=cM1A
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.