Re: CPAN integration
Moin Fabien Ninoles,
I've switched the subject, to point out that I want to continue on
somethink more productive than the 'Joey calls me an idiot' flamebait.
> 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.
The main difference between the way a ActiveState Perl module installes
and a Debian Module installs, is that ActiveState installs from blib/
as usual, while debian just patches the files into /usr/lib/perl5.
The Debian way is broken, if we think about perllocal.pod and other
things that are done during a 'make install' in a Perlish way.
> Seems the simpler solution for users that want to make their own packages.
unfortunately building a PPM is not so simple, but this is because of NT
being a rotten target for free software.
> The ppd file can be optional since is not useful into the deb (but can be
> included btw).
it should be trivial to parse the XML ppd, to build a Debian control.
> 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.
<SOFTPKG NAME="XML-Edifact" VERSION="0,44,0,0">
<TITLE>XML-Edifact</TITLE>
<ABSTRACT>an aproach towards XML/EDI as a prototype in perl</ABSTRACT>
<AUTHOR>kraehe@copyleft.de</AUTHOR>
<IMPLEMENTATION>
<DEPENDENCY NAME="Digest-MD5" VERSION="2,09,0,0" />
<DEPENDENCY NAME="XML-Parser" VERSION="2,27,0,0" />
<OS NAME="Debian/GNU/Linux" />
<ARCHITECTURE NAME="i686-linux" />
</IMPLEMENTATION>
</SOFTPKG>
we would need to extend this PPD generation to point out which Perl
was used to build the blib/ - to check it this should go into binary-all
or binary-i386, would need a check on blib/arch/.
> 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).
About Copyright - This needs only to be checked once for each module -
99.9% of the modules are distributed under the same terms as Perl itself.
The remaining should go into debian/dist/*/non-free, and need their own
Copyright notice.
About Version number - this can be found in the ppd.
About Changelog - use Changes if they exits, ignore them if not.
> 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).
My idea is, that Debian is not a generic Unix, so ExtUtils::MM_Debian
derived from MM_Unix would the way to go for a seamless Debian/CPAN
integration.
Moin Michael Alan Dorman,
> Because anything else is *impossible* to reliably integrate, debug or
> otherwise claim to be demonstrably working in what is suppsed to be a
> internally consistent, largely plug-and-play distribution.
I have to agree at that point - Debian's way is fine for me for any
package I just use. But its to inflexible on some packages. Without
prepacked Debian Perl Modules, other Debian Packages wont be able to
reference them.
> Sure, you can add things on---hell, you can use CPAN with our perl-5.005
> packages, if you want, you don't _have_ to use debs of other-than-core
> modules at all
no - Those Perl modules are not known to dselect, if I install them
by hand, or if I use CPAN. We need a MM_Debian, to integrate Perl into
Debian, so if I type 'perl Makefile.PL && make && make test && make install'
I want that those installation apears in /var/lib/dpkg/status. And I want,
that the Debian dependencies are right.
> But, as I said before, if you want to go this route, fine, use CPAN,
> not our pre-compiled packages. It'll work.
If I use CPAN on /usr/bin/perl, things might break on next dselect.
If I use my own /opt/perl-5.6, I should !NOT! add /usr/lib/perl5,
as many old Debian Perl Modules install in /usr/lib/perl5 and not
in /usr/lib/perl5/5.005/ where they belong.
My current solution is a /usr/share/debian-perl/{Debian,Dpkg} symlinked
to /usr/lib/perl5/{Debian,Dpkg}, and included in @INC. But I still hope
that it would be possible to call :
perl 'use CPAN; install Bundle::Debian;'
Currently those named 4 Debian modules, make a maintenance using
autobundle impossible. Perhaps somebody more polite than me should
try to convince Joey to recode his stuff conforming to Perl coding
standard.
> Learn to create the debs yourself, then. It's not hard---in fact, you
> can do most of them using a template where only about five lines
> change, and it only takes about five minutes a shot.
It's imho easier to build Debian Packages by hand (using AR and CPIO)
than to use the scripts provided by Debian - But I may change this
opinion next year when I've found time to read all the f*cking manuals.
> Of course, some would suggest that the nigh-mechanical nature of the
> process suggests it should be automated,
It should be automated in a way, that you should not think about
running a Debian when installing a Perl Module. But any module
should be checkt by a human maintainer !BEFORE! its uploaded to
the Debian archive.
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
Reply to: