Re: CPAN integration
On Sun, Jul 16, 2000 at 11:01:44PM +0200, Michael Koehne wrote:
> 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.
OK, I'll try to understand on which points we differ if any, on which one
we agreed, and on which one we still have no opinion/solution at hand.
I also remove all the points where some Debian Perl Packages are broken.
There are a different issue which can only be work with the different
maintainers. Keep in mind that the only thing we ask from the maintainers
is to follow the Debian Policies (which included a Perl Policy). I have no
strong issue about making all Debian Perl Modules, CPAN Modules. Eh! Perl
doesn't required you or any distribution for doing so, is it? However, by
standardising the way Debian Perl packages are construct (and following
the CPAN Perl Standard), we can help the issue a lot, IMHO.
>
> > 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.
That's just a design decision about how the package will be composed.
Debian choose, maybe wrongly, a long time ago, to not have relocatable
code (that's it, files store in package with the full pathname related
to root). I think some redhat packages are relocatable because they should
extract themself from /usr or /usr/local... However, I miss to see how this
can be wrong, perl modules should have a standard locations when integrated
in perl... elsewhere, you can always modify the standard location when rebuilding
the package.
>
> 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.
There is issue I don't know about... Can you elaborate a bit?
>
> > 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.
Not PPM, deb using dpkg-deb. A simple
mkdir -p tmp/usr/lib/perl5
mv blib/* tmp/usr/lib/perl5
[ any other need treatment to install all the files at the
correct place. ]
mkdir tmp/DEBIAN
than populate the DEBIAN dir with all necessary control file and run
dpkg-deb -b tmp package.deb
and you're done. In fact, that's all what a debian/rules binary target should
do with the exception that tmp is replace by debian/tmp and that the
dpkg-deb is done through dpkg-buildpackage instead. Everything else is special rules
to ease the task for extracting changelog information, get dependencies information,
build multiple binaries packages, compress documentation, create installation/runtime
script and registration procedure, create the source package files, the changes files,
sign everything and many other little things. devscripts, debhelper and yada are just
optional helps but still very useful. So debian/rules is just the Makefile.PL of
Debian, for anything debian related.
>
> > 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.
Yes, but we can also directly create all the control file with a special
version of WriteMakefile() since we have all the informations already extract
from there... However, it's more an implementation issue, I think. Are you OK
if we state that we must extract the information directly from the CPAN source,
whatever the mean used?
>
> > 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/.
Well, I would have search a long time for this one, since all modules seems
to create the blib/arch tree... Only somes are empty... However, I prefer
to include an override mechanism so we have it when we need it (Just imagine
if we already have the versioned Provides in dpkg from the beginning, how
much it would have it ease much of the transition like the perl to perl5
one...)
>
> > 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.
We can make such assumptions. Sorry to be stiff about this but we should take
care of this and give the possibility to the maintainer to extract the information
from the package wherever it is. The solution could be the same as for ChangeLog:
a special file named, eg, COPYING, with way to override this way. Personnaly, I
think that assing a pointer into the ppd xml description will be a good thing
both for us and for the Perl Community. Same thing for the Changelog later.
>
> About Version number - this can be found in the ppd.
Which is the same find in the Makefile.PL... Unless some CPAN packages used
special dirty trick to generate the Version Number.
> About Changelog - use Changes if they exits, ignore them if not.
Quick hack :( we should be able to indicate another one if it exists.
>
> > 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.
Agree with you, but only if needed (I think most of MM_Unix can be configure
to fit the Debian Way[TM]). My point was that I don't think that make a
MM_Debian that create, for example, a debian/rules and build everything this
way is a Good Thing... I think we can agree on this too?
>
> Moin Michael Alan Dorman,
>
[snip]
>
> > 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.
Can we replace 'perl Makefile.PL &&... && make install' by something else?
Personnaly, I will prefer to stiff to the necessary steps, not the semantic
of the command line.
[snip]
>
> > 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.
Details... I'm pretty sure you can learn it all simply by browsing over
them and start with a simple debian/rules example (I never create any
debian/rules... simply copy or generate some using deb-make and consors).
>
> > 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.
Yes, but for me I regard this as two things since creating a complete
"uploadable" debian package can be quite time-consuming. Many shortcut
can be taken for local needs. However, creating an automation tools for
creating, maintaining and updating a Debian Perl package is a fair goal,
IMHO. If the two can be made compatible so that a maintainer could try
a module locally than decided to ITPed it, it can be done using the same
step. Especially, I would like to have a way to do something like
apt-get source libxml-parser-perl &&
cd libxml-parser-perl-oldversion &&
debian/rules cpan-update &&
dpkg-buildpackage -rfakeroot -b -uc &&
su -c 'dpkg -i ../libxml-parser-perl_new-version_arch.deb'
and have a new package install. For sure, this all can be done in a script with more
error checking. But eh! it's mostly time to code (... hum... may be next week,
I don't think I will have any time during the OLS).
>
> 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
>
--
-------------------------------* *-------------------------
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: