[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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">
	<ABSTRACT>an aproach towards XML/EDI as a prototype in perl</ABSTRACT>
		<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" />

  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

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

> 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: