Re: vn-cclan package naming conventions and repository organization

On Thu, 2003-05-08 at 06:19, Daniel Barlow wrote:
> Indeed.  What was _supposed_ to happen is that a package of the form $name 
> might be converted to cl-$name by an asdf->vendor_package_format
> converter tool, so we'd have $name.tar.gz (upstream) and cl-$name.i386.rpm

That makes more sense.  I'll fix the packages that are up there now.

> My _personal_ opinion is that if cclan is not going anywhere right now
> it really isn't due to poor package naming conventions - it's because
> it's easier for most people to find some web or ftp space of their own
> and put the files up there.

Do you think that's because the current mechanism is too cumbersome or
because it will always be easier for people to put things up in their
own space?

> I think we need to be primarily in the pointers-to-packages business,
> not necessarily in the package hosting game itself.  I'm going to add
> a :package keyword to CLiki to do what the :download (formerly >)
> keyword should have done had I thought to impose a standard package
> format for the download at that time.
> 
> :(package "http://www.example.com/my-lisp-package.tar.gz")

There are some definite advantages of a central repository over a
collection of links.  Robustness, ease of implementation of support
tools, mirroring, etc.  Do you think it's just to much overhead?  It
does seem to work well for cpan.

> The proposed rules for using this will be
> ...
> (2) must be the location of the cclan/ASDF System package for which
>     the page is named.  That is, the page name and package name are
>     identical.
> :(package "http://www.example.com/my-lisp-package.tar.gz")

How we handle namespace clashes in this scheme?  For instance, what if
we have a md5 for sbcl and an md5 for clisp?  The flat namespace of
cliki does have some advantages but, like all, wikis, people will have
to start building implicit namespaces since there aren't any explicit
ones.

It also makes me a little nervous that you can't tell which version of a
package you're downloading until you've unpackaged it.

> The meta files are for archive node maintainers and control which
> version of the package is current, and which should be moved into
> archive directories or deleted.

Ok. Memory coming back to me now...

As a client of vn-cclan, there are several things I want to be able to
find out about a package before I download it:

1. What does it do?
2. What's the latest version?
3. What lisp implementations does it support?
4. On what other packages does it depend?
5. What's been changed since the last version?

It would be great if this could all be derived automatically from the
package contents, perhaps from the .asd itself.  Have a look at
http://search.cpan.org/author/SREZIC/Tk-Splash-0.10/FastSplash.pm for an
example of the cpan interface, which I think is pretty nice.

It seems like it would be much easier to build something like this with
a central repository, but I suppose it could be done either way.

Another thing that CPAN does well is allow several indices of packages. 
You can browse by Author, Category, or Name.  If we had all the
meta-information above available we could build these indices
automatically and the on-disk heirarchy wouldn't really matter much.

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

iD8DBQA+unv5U4Jq/wH1PVERAgr0AJ4hlotBYvqNhv5Lshr9vdU9QD47EACg5tnb
J4K4H84DAi+qZoY1+RJU6UY=
=zMRL
-----END PGP SIGNATURE-----