Re: a couple of vn-cclan package procedure questions

On Fri, Jun 21, 2002 at 07:09:09PM +0100, Daniel Barlow wrote:
> I think our desired end state should be, where possible, that upstream
> package authors (or maintainers) take on the .asd files and maintain
> them themselves - whether or not they then want the package to appear
> in cclan.  I would encourage package authors to
> 
> 1) package in .asd format,
> 2) create a cclan page with the same name
> 3) that has an appropriate download link 

I'd like to see this happen too.  Like CPAN, it would be nice if the
asd was the official release format.

> If and only if you want to maintain them, or you can persuade the
> upstream (the clocc maintainer, or perhaps where contactable the
> original author) to absorb and keep hold of the asd system definition.
> My guess is that clocc maintainers will probably not want to do this
> as I think they've standardised on mk-defsystem.  Upstream upstream
> people might though, possibly.  If they're still around.
> 
> For stuff which never changes (pgutils being a good example),
> "maintain" is essentially a no-op task, so I don't want to discourage
> people from e.g. packaging the RT code or MEMOIZATION or anything like
> that.

Seems reasonable.  I'll probably limit myself to packages like pgutils
for the time being.  I'd like to have something equivalent to the
url & xml handling code in clocc, but it might be more trouble to
disentangle it than reimplement it.

> I don't think it makes sense to prepend cl- on the vendor-independent
> packages any more than  it would make sense for all those CPAN
> libraries to be called Net-Telnet-0.16-Perl.tar.gz

Agreed.

> > 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.
> 
> The domain-style names are another kettle of fish, actually, as (at
> least in the case of net-telent-*) the ASDF system also has that name
> - it's not just the tar file that got renamed.
> 
> The problem is that, for example, we potentially have three different
> MD5 packages which probably have different APIs or performance
> characteristics (Pierre Mai's, Fare's and one other whose provenance
> currently escapes me) and will sooner or later need some method to
> tell them apart.  If you think that CPAN has managed without this,
> just try searching it for MIME packages and try to determine which
> goes with what without looking at the readmes.

I guess it's really a namespace issue, isn't it?  We will have clashes
if we use package names like md5-x.  I think those clashes will be
rare enough that I'd rather not saddle the entire archive with
domain-style names and deal with the clashes as exceptions to the
rule.

> The end goal is that there be no separate asdf package, so in that
> case it wouldnt matter that they have the same name; they have the
> same content too.  In the Real World(tm), though ...
> 
> > 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
> 
> No, but -
> 
> * I think we need to leave the tar.gz on, because asdf archive nodes
> around the world will already know what content-type to serve tar.gz
> as (or, depending on protocol used, asdf archive node _clients_ know 
> how to guess it correctly)
> 
> * I think 'cclan' is probably a better affix (is that the right word?)
> than 'asdf' for distinguishing changed-by-us packages from the originals
> 
> * I don't really mind if it goes on the start or on the end

So we'd have date-1.0.tar.gz in the case of a cclan-native package
like date and md5-pm-1.0.tar.gz in the case of a forked/assimilated
package and uffi-cclan-1.0.tar.gz in the case of a wrapped or imported
pacakge?  Seems reasonable.

One more question.  Would it be helpful to add a "supported
distribution" property to asdf?  I know a few of the packages I've
worked on only work in sbcl or cmucl.  Maybe we should make this
explicit?

-- 
miles egan
[email protected]

OpenPGP/GPG Key 0x01F53D51 @ wwwkeys.us.pgp.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9E4HwU4Jq/wH1PVERAu5cAKDdph4MAZcFAVTQYlCwOvKjLW9IjgCg2/y9
rtqA9rZ/vhlQpDhbHywOuwI=
=w5oz
-----END PGP SIGNATURE-----