* Timothy S. Nelson (wayl...@wayland.id.au) [090529 11:26]:
> 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 :) ).
Once some people want to spend time on details of the subject, I suggest
to revive a separate mailinglist for it. The list which we started two
years back was never used. Installation/distribution is a complex matter
with many aspects to be discussed, so deserves its own list simply not
to bother the (quite independent subject of) Perl6.
>> Who (besides Perl people) expect 5.10 after 5.8?
> Err, lots of people?
> kernel-2.6.27.5-117.local.fc10.i686
Eh, yes of course. That problem is only inside perl programs, where version
numbers are considered floating point numbers. Where 5.8.8 == 5.008008 ==
5.008_008. And then you have test versions like 68.17_02, which are broken
floats and therefore flagged as development versions.
In general, there are many versioning schemes which do often look alike,
but do have subtile differences.
> Allow me to point out that all the package managers out there have
> solved this problem, so it must be solveable.
Yes... but that also means that for some packaged products, versions need
to get translated into a different versioning scheme.
> 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 would like to add
. cpants information
. cpan-tester reports
. code-only extracts # for small systems to install Perl
. pod-only extracts # to add to code-only systems on demand
. tests-only extracts
. deb packages
. rpm packages
. pieton distributions
. etc
Oh, and then without name-space conflicts. And maintained by a small
set of people.
One of the main problems with the current set-up is the very limited
pre-information about the installation available to CPAN.pm. It
downloads a 02packages.details file which does not contain info about
dependencies and such. One of the much heart complaints from normal
Perl users is about the flood of unpredictable changes in the system
once you install one module. Linux Distributions do also install many
packages with one change, but are able to present that far more cleanly.
Simply because they have more information at the start.
What you probably need: dependencies, package size, licenses used,
supported platforms, short description.
An other consideration is the size of the 02packages file. This is now
750kB. It now lists only the last versions of each of the packages (not
distribution!) in CPAN. But, when Perl6 introduces parallel versions,
you may have people who actually want to use that feature. Business
people other want an explicit module version, not the newest one. This
means that the size of the 02packages files explodes with
N times avg.nr.versions
times number.of.targets
times useful.additional.metadata
My internet connection is very fast. Yours probably as well. We don't
care about this, do we?
> 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).
Most projects die. The only reason why CPAN hasn't died is because of
enormous effort by Andreas and a small group of other people. When
Andreas is overrun by a Berlin bike, we have a serious problem. It is
hard to find dedicated maintainers, as many Open Source projects have
found out.
IMO, fragmentation is crucial: you can not stack the load on a small
group of dedicated people because they burn-up that way. People must
be able to fork their own pet project, like search.cpan.org. And yes,
that enlarges the chance that such a project dies. But that's normal
evolution. At least, you have dedicated people with a work-load of their
own choice.
Considering above, I changed the concept of "CPAN" from a special
thing for Perl5 only, into: "collecting information is a basic need
for groups of people". People start together an "archive" (collection)
with a certain purpose. They lay-down the rules of that archive (who
has super-user rights, permitted licenses, etc). And then, they have
a standard implementation for collection needs: mirroring, versioning,
various up- and download protocols, release under embargo, ..etc.
A lot of maintenance effort by the current CPAN maintainers will not be
needed anymore. Maintainers can focus on the quality of the content.
Perl6, Perl5, parrot, pieton, python, PHP, family pictures, business
documents, ...
And yes, I you really want to make 1 huge archive where everything can
be put in, as suggested here, then it is still possible. That is how
ftp-servers are organized.
--
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
m...@overmeer.net soluti...@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net
