Re: State of the Art wrt XML/XSL.
On Sun, Jul 16, 2000 at 06:58:34AM +0200, Michael Koehne wrote:
> Moin Fabien Ninoles,
>
> > I doesn't understand much... Did ActiveState MakeMaker download a compiler
> > too or simply download the already compiled binaries from their sites.
>
> have you ever seen a windows user who is using a C compiler ?
>
> So ActiveState 'precompiles' the Perl Modules. Their step of making
> a ActiveState PPM is :
>
> perl Makefile.PL && make && make test && make ppd && make ppm
That's the part I misunderstood. I doesn't know that ppm repository
exist. It mostly just like the debian repositories but for Perl for
Windows exclusively, isnt? So the developper run the above command to
create a ppm package which can be installed after this by users that
doesn't have any C compiler. Look like the same package concept that
we find everywhere in the Linux world.
>
> To translate this to Debian :
>
> perl Makefile.PL && make && make test && make ppd && make deb
>
> should produce a libfoobaa-perl-*.deb with the right dependencies.
>
> 'make ppd' does work on a Unix system also. Take a look at it.
Seems the simpler solution for users that want to make their own packages.
However, I would like to see it integrate to the entire package system,
source included. So, a package done this way could be upload to debian
and the source package could be in most case update directly from CPAN.
However, all packages should be self-contain so someone could take a debian
source CD-ROM and recompile everything.
To acheive all this goals, maybe the right solution will be to create
a debian directory with a rules file that will do all the previous commands
(perl Makefile.PL && make && make test && make ppd in the build target).
The ppd file can be optional since is not useful into the deb (but can be
included btw). We would have to change some permissions on files (must pm
I see installed themself a la RH - which is all a-w including for root),
maybe some locations also and thing like this. That's why I think an override
mechanism is needed. So the results will instead be:
create perl-deb && dpkg-buildpackage -rfakeroot $(OPTIONS)
where $(OPTIONS) could be set by the user to nothing or -us -uc -b for simply
constructing the binaries.
All the problem is in the override mechanism (for special debian/rules with
multiple binaries for example, or for modules that don't only consist of
perl scripts like XML::Parser). It's sad that the ppd doesn't make this kind
of difference since this will greatly help us. We also have to extract the
copyright informations (hard since no standard location exist for CPAN),
dependencies, author, version number (easy using dpkg-shlibs and the information
set into the Makefile.PL), changelog (hard also since the location vary - I see
at least three: one README (XML::XPath) and two different /Changes/i).
This all can done by creating a Bundle::CPAN::Debian module as well as a
ExtUtils::MM_Debian module if needed (but I think MM_Unix will suffice).
With some luck, most override will can be forward upstream... may be by usign
some special DEB_ options just like the PPM one. @DEB_PACKAGES, %DEB_PACKAGES_ARCH,
%DEB_PACKAGES_FILES, $DEB_COPYRIGHT and $DEB_CHANGELOG come to my mind...
This is a big project and keep in mind that I'm not a perl hacker... even not
a wannabe! ;) So, if I say something stupid here, just correct me. I'm willing
to learn, not to be insulted ;)
>
> Bye Michael
> --
> mailto:kraehe@copyleft.de UNA:+.? 'CED+2+:::Linux:2.2.14'UNZ+1'
> http://www.xml-edifact.org/ CETERUM CENSEO MSDOS ESSE DELENDAM
Ciao!
--
-------------------------------* *-------------------------
Fabien Niñoles / / fabien@tzone.org
Chevalier Servant de Sa Dame / / C15D FE9E BB35 F596 127F
Veneur Gris par la Clef / / BF7D 8F1F DFC9 BCE0 9436
Chaton pour Debian / / http://www.tzone.org/~fabien
--------------------------* *------------------------------
Reply to: