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.
