On Friday 29 May 2009 1:51:40 am Mark Overmeer wrote:
> 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.
Okay, I will readily admit that there is a real need to have there be a more
clear separation between these two separate things which are both called CPAN.
> 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.
Here I'll have to disagree, for several reasons.
* The structure of the archival system will heavily impact the structure of
the install tool
* If the archive does not provide sufficient information in a useful format,
then it may be difficult or impossible to delegate installation to the local
package manager. With the current CPAN architecture for Perl 5, it is
impossible for an external package manager to calculate dependencies without
first downloading the entire /source/ of all modules in the dependency list
*due to a limitation of the archive architecture*
> 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.
This feels like a straw man to me.
* Package managers are actually relatively stable. The .deb, .rpm, and .ebuild
formats (just to name three _big_ ones) have been around for at least 10 years
each.
* We don't need to provide everything in all formats - If the archive
structure makes automated conversion easy, then _each_ _distro_ can just run a
cron job to
* Sync with the CPAN archive
* Automagically build packages for their own distro
* Publish those packages (PPA for Debian and Ubuntu, overlay for Gentoo)
* Alien is really not a very good solution, as it only works for binary
distros, not source or hybrid ones (Gentoo, Exherbo, Arch) and even then only
a few binary distros are supported
> 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.
And once again we run into an issue: This workflow would require that each end
user, rather than using /only/ CPAN(PLUS)? or /only/ their package manager to
install, they are forced to use one to generate packages, and then the other
to install them! By providing a very open metadata spec, we can make it so
that neither the Perl community nor the end-users need to take on that burden.
Instead, it would go to the distributions, who are already well-prepared to
handle packaging. We'd just be providing the tools and material they need to
do so.
> > 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.
As I said above, it doesn't need to. What my mail was suggesting was mainly a
very information-rich metadata spec, which would contain enough information
that the distros could package the modules without needing much more than
that.
* For my first point, it merely says that the metadata must contain enough
information to run an installation process, which is usually the information
needed to build a distro package
* The second bulled adds the constraint that this should be doable in an
automated fashion
* The third bullet adds the requirement of /extensibility/, to meet the needs
of new platforms
* The fourth bullet says that it should not be excessively onerous to publish
a module that is well-formed
* The last bullet says that it should contain enough data to build something
like the CPANTS which already exists for Perl 5
> 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.
Agreed - and by providing a rich metadata spec, we can let them make those
choices themselves.
> 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?
I think we may have been talking past each other. These are essentially the
same requirements I laid out, though with different phrasing.
> 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.
This makes sense.
> PACKAGING IS NOT OUR BALLGAME!!!
But, we must provide enough material and tools so others can do it
_effectively_, rather than in the half-ass manner forced by the current CPAN
archive structure in the Perl 5 world.
