* Timothy S. Nelson (wayl...@wayland.id.au) [090529 12:02]:
> On Fri, 29 May 2009, Mark Overmeer wrote:
> * 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/
Yes. It facilitates organization of archives: exchanging releases
(f.i. software distributions), without the knowledge about the internal
organization of the archive. This layer ensures that various servers do
not need to run the same version of the archiving software: alternative
implementations can exist as long as they have a minimal subset of
features.
It contains things like
. protocol negotiation
. XML, YAML, Data::Dumper syntax?
. packaged with tar, cpio, zip, none?
. compressed with gzip, bzip2, none?
. transport protocol http, ftp, rsync, ..
. release addresses: archive name (URI), product name, version name
Quite simple.
> * PAUSE6; this is an actual network based on the CPAN6 software (see
> above). It also is not documented here.
Pause6 is one implementation of archive maintenance software. In the
first version written in Perl5, it implements things like
. archive maintenance rules
. uploaded release inspection
. actual storage on disk
. trust, licenses, authors
. sub-setting and merging archives
. mirror synchronization
. simple meta-data searches
. end-user downloads
These are all server-side things: the client code is very small! Client-
side, it is more like ftp (downloads are done via ftp, http, etc.
The simplest CPAN6 client is this:
wget http://cpan6.org/perl5/get?product=XML-LibXML
which gives you a copy of the seperate files in the last version
of XML-LibXML without packaging or compression via http from a mirror
nearby you. Then
cd XML-LibXML-0.69/payload/; make install
Something like that.
So: Pause6 is the logic behind our current Pause upload interface plus
all the maintenance tasks from CPAN maintainers.
> * 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)
Well, in my current implementation, CPAN6.pm is a faint layer on top
of CPAN.pm. It will search a little differently (search on the web or
local disk when using a CD, no 02packages.details), but downloads are
still managed by LWP.
>> 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?
CPAN archive and Perl install tools are fields of the software author:
his/her attempt to get software from the own disk usable on someone else's
system. Package managers are used by the end-user to have control over
their system. This is a different problem, each OS(-version) has other
solutions.
> Have you seen Software::Packager? It's a Perl5 module that's designed
> to create a "source package"* for any supported package manager.
What I see in the module is two-fold:
. some meta-data
. some wrapping (tar)
On the meta-data side, it is much too UNIX oriented and far too little.
It totally lacks any support for platform dependent problems like
. which charsets are supported by filesystems
. which characters have a special meaning on various OSes, and
how do install tools work around encountered problems.
(for instance a ':' in a name, unicode package names, ...)
. all kinds of important additional meta-data are missing, like
license. The Meta.YML is much more complete.
. the implementation is very UNIX centric
As indicated before, I think the transport wrapper, like tar, is totally
unimportant: it should be abstracted as a transport layer, hidden on
the application level of installation tools.
> 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.
My CPAN6.pm implementation transports a directory of files from the
source (author) to the end-user, without knowledge about the content
of that directory: whether it is one perl5.tar.gz or a dozen pictures.
In parallel, it uses a meta-data file for such release, which contains
cpan6, pause6, and release specific meta-data. For Perl5, it will capture
all of the Meta.YML info and more. For instance, it will add checksums
for all files, and crypto-signatures.
> I'd like to suggest a further terminology split:
> - 6PAN: command-line install tool
The term 6pan has also been claimed before.
I would say "pause6" or "cpan6" (no capitals)
> - CPAN6.pm: Module relied upon by 6PAN for interactions with Pause6
As my idea of CPAN6.pm is just a layer on top of CPAN.pm, the 6PAN
simply is the current CPAN.pm shell.
> - Software::Packager: Module relied upon by 6PAN for interactions with
> the local packaging system, and for installing files.
No, that is far from sufficient.
Each packaging system has some special needs: pre-install scripts, after-
install scripts, apply delta, platform dependent bug-fixes and work-arounds.
That is the work of the package builder. This package builder, just like
other service builders, like search.cpan.org, cpants and cpan-testers,
need access to as much strictly defined meta-data as they can, to extract
their specific needs.
IMO, it should go like this:
DEB service:
forever
foreach newly arrived distribution in $perl5_archive (1 wget)
download distribution (1 wget)
try to deb it automatically
or ask deb-admin to help creating a deb; next
upload generated deb to $perl5_deb_archive (1 wget)
sleep some time
The system(s) with (a copy of the) $perl5_deb_archive on it can offer
a standard deb interface (ftp) via the Pause6 "Store" (being files on
disk) Minimal effort!
Again, instead of the Perl people trying to generate as many different
package wrappers for linux brands to publish Perl software, I think
we should focus on simplifying that delicate task for the package
specialists. But leave that task to them. When we collect detailed
meta-data, then they have a light job.
> 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.
Very welcome!
>> 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?
Any collection can be kept in a Pause6 implementation, so also a whole
OpenSuSE repository. When a new version is released by them, they
can distribute the packages under embargo to the mirrors. Then, at a
certain moment of time, the embargo is lifted (by time, appearance of some
specific other module in the archive or by changing the archive rules)
Very simple!
Currently, ftp-server maintainers get a special email from SuSE that a
new release can be downloaded on some closed spot. Then, on a certain
moment, the ftp-server maintainer has to move this tree by hand to the
right spot... really that primitive!
>> 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?
The format is unimportant: syntax can be converted. It is about well-
definedness of the meta-data structure and interpretation.
>> . added with minimal hassle for the (often lazy) authors of
>> the code (usability)
> Masak was suggesting a tool to generate it.
Partially you can, partially you cannot. For instance, it cannot
automatically guess a license.
>> . extensible meta-data structure (future grow path by design)
> This is one reason I'm suggesting Software::Packager.
Software::Packager implements access to meta-data. That is always simple.
Interpretation is difficult. Give me any meta-data, and I can parse it
into Perl hashes... but don't ask me to interpret the content
(automatically).
--
Regards,
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
m...@overmeer.net soluti...@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net
