Front page | perl.perl5.porters |
Postings from October 2000
Re: [ID 20001009.009] what if cc changes?
Thread Previous
|
Thread Next
From:
Lupe Christoph
Date:
October 11, 2000 23:36
Subject:
Re: [ID 20001009.009] what if cc changes?
Message ID:
20001012074924.B1103@alanya.lupe-christoph.de
On Wednesday, 2000-10-11 at 09:33:57 +0100, Alan Burlison wrote:
> 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.
Sorry about the phrasage. I mean "like Alan's script does".
> > 3) Use a Perl-specific format.
> The last thing the world needs is YAPF (Yet Another Packaging Format).
There seems to be no useful cross-platform format right now.
It might be necessary to do a new one.
> > 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.
I guess I should not only rereadthat but also look at you script.
Right now I'm alittle too busy to do that.
> > 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.
... in the tarball/package yourscript generates? Fine!
> > 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?
When you try to make their life easier you make life more difficult
for the module and tool maintainers. I found .rpm and .deb sufficiently
similar to SVR4 packages to sope with them. The tools are a different
story, though.
> > 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.
What about creating the new Config.pm? That needs support from the
package itself.
> > 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.
Maybe we should forward the discussion on this to him and see
how/if he reacts?
> > 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'd prefer that, too. The one main gigantic evergrowing packlist bothers me.
And whateverthis will be, it will need support from MakeMaker. I just
fear people who do not properly list their PREREQ_PMs.Doing cpan-tests
I found just too many of those. Libraries are worse.
> I actually think that .packlists should be restructured as XML rather
> than the current format.
XML seem to be becoming the problem to end all problems. ;-)
Lupe Christoph
--
| lupe@lupe-christoph.de | http://free.prohosting.com/~lupe |
| "jryy vg ybbxf yvxr gur l2x oht qvqa'g erne vg'f htyl urnq." "lrc. gur |
| qbbzfnlref unir orra cebira jebat lrg ntnva." .... "qvq lbh frr gung |
| gbb?" "ubhfgba. jr unir n ceboyrz." User Friendly 2000-01-01 |
Thread Previous
|
Thread Next