* Alex Elsayed (eternal...@gmail.com) [090528 22:17]:
> While lurking in IRC, I've seen several discussions of what CPAN 6 should
> look like.
I would really like to see a split in terminology being used for the
various seperate problems. The traditional confusion about what CPAN is:
an archive or an install tool. Package manager discussions are in the
process AFTER the install tool: to distribute OS changes to be made.
In the messages on the list, I see people merge requirements of these
very independent tasks.
I think that package managers are not a "CPAN" related problem at all.
The Perl install tool decides which files it wants to have within some
file-system tree and versioned environment, and then package managers
distribute those files and meta-data.
Also, there are various different package managers around for Linux
distributions, and they tend to be replaced every few years. If you
want people to use Perl modules on their Linux systems in a convenient
way, you have to distribute each perl module in all of the existing
formats. Of course, a tool like "alien" can be used to simplify the
task of creating all these flavors.
IMO, that discussion should go in the direction of additional services:
the CPAN archive distributes what authors publish. The install tools
(CPAN.pm/CPANPLUS/successors) make that code fit in specific operating
systems. As a service, other people can publish the results of their
specific module installation via package-managers to the world, such
that those people can use they platform native software management
tools. Just like search.cpan.org is an independent additional service
on the CPAN archive.
> I personally believe that there are a few requirements for a package format
> that is sufficient for Perl 6:
> * It must enable packaging for both binary- and source-based distros
> * It must enable automatic generation of packages for supported systems
> (although it may well not be capable of it out of the box)
> * It must permit (or preferably help with) attempts to support new systems
> * It must be simple to submit packages in the correct format
> * It must enable the design and building of an automatic testing system
The worst flaws in software design are based on the idea that you can
organize the outside world. The Perl community will never be able to
push its packaging mechanism into Linux distributions. We may be able
to select the ideal packaging mechanism, and then they will wrap that
in their own packaging mechanism.
IMO, as Perl community, we should focus on the things we are good in:
have people contribute free Perl code in a simple and platform independent
way. Let package manager specialists do their job! They will NEVER be
satisfied by the choices we make for them.
To help package builders do their job simple and correctly, we have to
supply them with as good metadata as we can. Which means:
. as much as possible (sufficient kwantity)
. very explicitly defined structure and content (predictable quality)
. added with minimal hassle for the (often lazy) authors of
the code (usability)
. extensible meta-data structure (future grow path by design)
To get these things right is already an increadible amount of work... and
no-one else does that for us. There are so many improvements in this
area to be made in our current set-up already, which no-one picks up.
Does anyone like to see my wishlist?
See http://cpan6.org/papers/2008yapceu/ In the last example
http://cpan6.org/papers/2008yapceu/cache-release.xml
I show much more additional meta-data information than currently
provided my Meta.YML, but all very usefull for packaging tools and other
services. (I have used XML as syntax, because with XML-schemas I can
precisely describe the structure and content: quality!, but you can also
transmit the data in YAML, JSON, Data::Dumper,... that is just unimportant
syntax!!!)
One thing to mention: I have separated some meta-data into own
releases as well. For instance, in stead of including all kinds of
personal information (like email address) inside the distribution,
I let people make a release which contains that information just like
a software release. The released software only contains a reference
to the personal information. That means that people can upgrade their
personal information (make a new release of themselves) when the email
address changes. Of course, that exact content of "personal information"
is not an Perl6 issue, but it is solved in my CPAN6.
PACKAGING IS NOT OUR BALLGAME!!!
--
Regards,
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
m...@overmeer.net soluti...@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net
