Front page | perl.perl5.porters |
Postings from October 2000
Re: [ID 20001009.009] what if cc changes?
Thread Previous
|
Thread Next
From:
Alan Burlison
Date:
October 11, 2000 01:34
Subject:
Re: [ID 20001009.009] what if cc changes?
Message ID:
39E425F5.7F8B6EFC@uk.sun.com
Lupe Christoph wrote:
> Seems we have three ways here:
> 1) Use a tarball, like Alan does.
Actually I did this just as a hopefully useful script, I don't use it
myself.
> 2) Use "native" formats like .rpm, .deb, SVR4 pkgadd format.
I use this one - using the 'make a SVR4' variant of the same script.
> 3) Use a Perl-specific format.
The last thing the world needs is YAPF (Yet Another Packaging Format).
> I believe whatever is used should maintain the packlist on the
> target system.
Errm... mine already does - see the original mail I sent on the subject.
> It should also be available on every platform perl currently supports,
> and be supportable on any new platform.
.packlists are already produced as standard for the perl core and all
add-on modules.
> My limited experience with .deb, .rpm, and SVR4 packages suggests
> we should avoid number 2 as a general solution. The variations are
> too great, and some platforms have no such format.
Yes, but if the wherewithall already exists for creating such packages,
I don't see the problem with supporing them if people want them.
Sysadmins will usually be familiar with the native packaging format -
why make their lives more difficult?
> A pure number 1 does not deliver the functionality. We need to update
> the packlist on the target system, possibly create a customized
> Config.pm for the package, etc.
a) The packlist is already updated (see above). b) Packages like CPAN,
Net et al either have a configure script or will autoconfigure when they
are first run. Because the resulting Config.pm is not listed in the
packlist, when the package is bundled up and installed on another system
the config process is rerun. Trust me, it works.
> I think number 3 is the only sensible route, if it is a cross-platform
> PPM or not. We need an installation tool like pkgadd, rpm, or so.
> The format should support {pre,post}{install,remove} scripts.
Sigh. Go search the archives. I had a heated discussion with Dick
Hardt over this very subject when it was first raised. He was insistent
that PPM was the One True Way and that he would provide it for perl as a
cross-platform standard. Well, several years on and I'm still waiting.
I gave up working on the .packlist stuff at that point because it seemed
to be a waste of time, and because it worked well enough for my
purposes.
> Beneath this format we can use tar, cpio, or zip, or whatever is
> convenient. It should just have a supporting perl module.
Or RPM, or SVR4 pkgadd, or PPM...
> One thing to keep in mind is that people might try to add a package
> multiple times, maybe using downrev packages. They might also run
> into fixincludes-like problems.
>
> The package format and tool must detect this, and package dependencies.
> Think about a sharable library required by the perl module, that might
> not be there because that OS package was not yet installed.
>
> Doing the package generation right requires also a complex tool that
> can detect most such dependencies automatically (running ldd, etc.)
All these issues are already known or detected at the time the module is
originally built - all that it is necessary to do is to remember them.
What is needed are some slight modifications to the .packlist format to
add some missing attributes, namely module name(s), module version(s)
and dependencies. One wrinkle is when a module is installed that is
already in the core the files are listed in two places - the core
.packlist and the newly installed module's .packlist. For this reason I
think modules included with the core should have their own seperate
.packlists rather than being all stuffed into one.
I actually think that .packlists should be restructured as XML rather
than the current format.
--
Alan Burlison
Thread Previous
|
Thread Next