On Fri, 29 May 2009, Mark Overmeer wrote:
* 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.
Ok, here's some terms I've picked up:
These are from Mark's Paper:
- CPAN6: a general infrastructure to create and distribute archives
- Pause6: one implementation of archive management
- CPAN6.pm one transport mechanism to install Perl modules from Pause6
archives (or presumably any CPAN6 server)
I've rephrased them in S22 as:
* CPAN6; this is a piece of software for managing an archive network (such as
Pause6, below). This is not specified in this document; see
http://cpan6.org/
* PAUSE6; this is an actual network based on the CPAN6 software (see
above). It also is not documented here.
* CPAN6.pm; this is a piece of software that starts with what it can get
on PAUSE6, and attempts to give you an installed perl module (this is a
replacement for CPANPLUS/cpan2dist)
I've replicated that here so that Mark et. al. can verify or deny that
we're thinking the same thing. Please keep in mind that if I got them wrong,
I'll be using the S22 definitions in the rest of this e-mail.
The area I'm interested in overlaps mainly with CPAN6.pm.
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.
The terms you've used here are so general that they could describe any
one of a number of things. I'd like some concretification or something.
Example?
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.
Have you seen Software::Packager? It's a Perl5 module that's designed
to create a "source package"* for any supported package manager.
Unfortunately, CPANPLUS has never used it. This is the part of the whole
discussion that interests me the most, because it's where my problems have
lain.
Just for the record, I'm interested in having a Software::Packager
port/rewrite be part of the installation tool; overlapping what you're calling
CPAN6.pm.
I'd like to suggest a further terminology split:
- 6PAN: command-line install tool
- CPAN6.pm: Module relied upon by 6PAN for interactions with Pause6
- Software::Packager: Module relied upon by 6PAN for interactions with
the local packaging system, and for installing files.
If there are no objections, I'll pop these in S22 as well.
Having clarified the terms, I'd urge people not to use the term "CPAN"
without qualifiers in the discussion any more, as it conflates things.
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.
Are you arguing here for eg. a yum/apt/whatever repository on Pause6?
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)
Just to clarify, this is what I want :).
* 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.
Agreed. I've chosen my package manager, and I'm sticking to it :).
I've been in CPAN(5) purgatory for years because of this.
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.
The choir will now sing! :)
To help package builders do their job simple and correctly, we have to
supply them with as good metadata as we can. Which means:
Am I right in presuming you mean "As good a metadata format?
. 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)
Masak was suggesting a tool to generate it.
. extensible meta-data structure (future grow path by design)
This is one reason I'm suggesting Software::Packager. It will do
stuff in-memory, and if we want to read stuff in from another format someday,
we just attach a different PackageReader. Note that Software::Packager only
does PackageWriters at the moment; PackageReader was part of my redesign I was
working on before I decided to target Perl 6, but it means we could accept the
data in a variety of formats; has the user already created an RPM spec file?
No worries, we can get the data from that. Have they created a .deb? No
worries; given an appropriate reader, we can get data from that too.
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!!!
It's mine, and that's where I'm coming at this from. Pre-packaging is
our ballgame (we agree here), but so is the interface to packaging systems.
That last point is where Software::Packager comes in.
HTH,
---------------------------------------------------------------------
| 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-----
