On Fri, 29 May 2009, Mark Overmeer wrote:

* Daniel Carrera (daniel.carr...@theingots.org) [090528 16:07]:
Mark Overmeer wrote:
In March 2006, Sam Vilain and I started to think about a new CPAN
what we named CPAN6.  There is a lot of information about the project on
http://cpan6.org

I know about CPAN6, thanks. It's come up a couple of times on IRC.
Perhaps you could hang out on the IRC channel so we don't have different
people going off in different directions with CPAN.

It's not a discussion like "let's make a change to the current set-up",
so IRC doesn't seem to me a good spot to discuss it. I gave various
talks on YAPC's and interviewd a few of the CPAN maintainers.  Workshops,
Hackathons and YAPCs are more suitable.

I support Daniel in that you should expect to miss things if you don't hang out on IRC. But I support Mark in the idea of longer formats, although I think 30 pages is a bit long. I've skimmed the document, though, enough to know what I need to know at the moment, I think (please correct me if I'm wrong).

I'd like to suggest to Mark and Daniel that, seeing as I won't be making it to any Perl event outside Australia, and maybe not even some inside, and Mark can't keep up with IRC (my sympathies there), that the best place for such a discussion might be a mailing list such as p6l! (No sarcasm intended -- I'm saying you're doing the right thing, keep it up :) ).

Trying to keep-up with normal email is already a daily struggle.  Besides,
having 9 hours time-difference with the West Coast doesn't help: when they
wake-up at 8, I am just getting my 2 yr old son from Kindergarten back home.
And when he finally sleeps, I am tired ;-)

Mark: There's usually someone awake somewhere, even if it's only me here in Australia.

DanielC: Don't argue with his time management until you have children. I don't, either, but I can see what a time-sink a family would be (even good things have their downsides).

A) Can we add "version", "target" flags to CPAN metadata? I was
thinking  that current modules would all be version=1 and
target=perl5.

CPAN does not have an official concept of version numbers on distributions,
but only on the pm files which are inside the distribution.

I know, thanks. I was suggesting a change.

I had a discussion of two days about "versions" with Sam Vilain.  What
we came up with, is that there is only one solution: versions need to
be strings without meaning.  Of course, you can help yourself using some
kind of logic sequencing these strings, but everyone has different ideas
about how to do that. Who (besides Perl people) expect 5.10 after 5.8?

Err, lots of people? The Linux kernel does its versions this way, so most people in the Open Source world are familiar with it.

        RPM seems to be able to handle things just fine, too.  Example:

kernel-2.6.27.5-117.local.fc10.i686

Version = 2.6.27.5
Release = 117.local

The Version can be split up on the dots, and each compared numerically if available, and as strings if there are non-numerics.

Allow me to point out that all the package managers out there have solved this problem, so it must be solveable.

The solution is simple: each release has a unique version string. The
release also lists as meta-data what kind of follow-up it is to which
existing release.  For instance:
  5.10.0       diverts from 5.8.8  (upgrade)
  5.8.9        replaces 5.8.8      (update)
  5.10.1-blead diverts from 5.10.0 (devel)
  5.10.1       replaces 5.10.0 and 5.10.1-blead (merge)

It may be useful to have these as recommendations, but I would hope that user policies and choices would be able to override them.

D) In addition to target=perl5 and target=perl6 we could have target=parrot.

IMO, we need many more.  What you call "target" is actually a namespace.
The current CPAN archive has only one target.

Target, namespace, same difference. It's an identifier to divide modules
into categories.

Well... do you need all archives to share one infrastructure?  I think it
is nicer to have people being able to open-up CPAN-like archives with
additional features.  For instance, if someone wants to publish pre-compiled
PIR versions of modules, then s/he should not need the assistence of the
core CPAN.  With an URI namespace, you address an archive where you can
find the data.  A part of that namespace (URI fragment) could be a target
within the archive.

While I've no objection to building the end-user software to support multiple repositories, I know that there are certain segments of the community who are very very keen to keep everything in the one repository. I'd agree with them, on the following conditions:

-       CPAN accepts packages in Perl5, Perl6, and anything else that runs on
        Parrot
-       Some of the other changes mentioned here get implemented (ie. Larry's
        idea of putting binary packages on CPAN as well)

I have also been wondering about the idea of making CPAN a clearing house that simply refers to other repositories, tells you where to get them, keeps the doco, and the like. But I decided against that too.

The big problem with the multiple repos idea is that, unless each has a large organisation behind it, they die (witness the DAG RPM repo, which seemed deadish last time I looked; the packages are still there, but no updates seemed to be being made). CPAN, because it has a large enough organisation behind it, has a number of people behind it empowered with keeping it going. People don't want to have to keep up with the fashionable repos.

        Or think of it as reducing the truck number.

When I started writing this, I was semi-neutral, but I think I just convinced myself.

F) In summary, we have a possible course of action:
There is a lot more structurally problematic.  Please read one of my
papers on the cpan6.org website.
I have scanned through the first one. It's 30 pages...

Oh, that's the small one.

That's the one I scanned too. I saw some things in there that I thought were good ideas, and none of the ideas you seemed really keen on conflicted with the things I was really keen on. Some of your ideas in e-mail might, but we can continue discussing, and see what we get :).

        :)


---------------------------------------------------------------------
| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayl...@wayland.id.au    | I am                           |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----

Reply via email to