On Fri, 29 May 2009, Mark Overmeer wrote:
* 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.
What's the mailing list called? And is it gone, or active-unused?
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.
I believe Perl 6 explicitly supports a "version" type that handles
some of this (I know that's not a general solution, but still...).
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.
That may be the case, but it's probably the worry of
Software::Packager. Hopefully we can make it cope.
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
Fixing this++
My internet connection is very fast. Yours probably as well. We don't
care about this, do we?
I do! :)
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.
The thing is, CPAN is mirrored everywhere. If fragmentation occurs,
some parts that are not mirrored may not be completely lost. I guess that's
my fear.
Anyway, I hope some of this helps.
:)
---------------------------------------------------------------------
| 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-----
