Front page | perl.perl6.language |
Postings from May 2009
Re: CPAN -- moving forward
Thread Previous
|
Thread Next
From:
Daniel Carrera
Date:
May 30, 2009 16:48
Subject:
Re: CPAN -- moving forward
Message ID:
4A21C5CE.7000104@theingots.org
Daniel Ruoso wrote:
> The leap you make from the source package to the different binary
> formats is overlooking a lot of details. It would be interesting if you
> could take a look in the previous discussions on the matter.
I'll be happy to. I was just trying to make a small iterative step on
Synopsis 22. I know that there is a wide gap between that and binary
formats. But I wouldn't do anyone any favours if I spend a lot of time
on my own trying to make a complete solution. At least now you can point
me to the relevant discussion and I'll be happy to read it. I just need
a URL link.
>> 1) A package format.
>
> This is supposed to be a source format, but different from current model
> used in CPAN, it's pretty clear already that it can't include a "build
> system", like ExtUtils::MakeMaker or Module::Install.
>
> There's already some consensus that this "source package" format should
> describe what it contains, not how it should be built or installed. For
> instance, it should only say something like "in the lib directory
> there's a set of STD Perl 6 modules that don't require any low-level
> integration".
Ok. Thanks for the info. Notice that I didn't assume anything one way or
the other on the page I wrote. Just some additions to S22 (mainly the
manifest file). I tried not to make many assumptions precisely because I
don't know the previous discussion.
> 2.0) Build tool
>
> Before installing it, you need to create a "installable package", or
> "binary package" (that's what CPAN plus does today). The thing here is
> that the process of transforming the "source package" into an
> "installable package" will be specific to the Perl implementation, to
> the Operating System and to the vendor of the Operating system.
>
> That basically means "it's implementation specific", and each
> implementation should do its best to provide that support. For instance,
> rakudo might want to compile the modules to Parrot Bytecode, while
> mildew might want to compile down some things to C.
Seems logical.
> If you're in an OS that provides a rich package management system, it
> means you can generate native packages, otherwise you need to implement
> the next step as well, which is:
>
> 2.5) Install tool
>
> In systems where we don't generate native packages, we need a package
> manager on our own. It should be capable of taking any "installable
> package" and making it available in the system, checking all
> dependencies and other requirements..
Yes, certainly.
>> 3) A high-level install tool, analogous to yum or apt, that uses the
>> CPAN network and resolves dependencies.
>
> I do think this is very much implementation-specific, for instance, in
> Debian, with little work you could simply use apt-build to get your
> packages built and available for installation with apt-get.
In Debian there is both apt-get and aptitude. Two different
implementations of a high-level package manager wrapped around dpkg. In
the RPM world there is yum and urpmi as well.
> In summary,
>
> The part 1 is really the critical issue, 2.0, 2.5 and 3 are mostly
> implementation specific and are considerably easier to adapt than the
> things in the part 1. We do need to find a very solid way of describing
> what the package contains in order that implementation-specific build
> tools can make them work.
Yes, indeed.
Most of what I put in the wiki page is an iterative step on the package
format described in Synopsis 22. Should we start talking about the
package format then?
Daniel.
Thread Previous
|
Thread Next