* 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