develooper Front page | perl.perl5.porters | Postings from October 2000

Re: [ID 20001009.009] what if cc changes?

Thread Previous | Thread Next
Lupe Christoph
October 11, 2000 23:36
Re: [ID 20001009.009] what if cc changes?
Message ID:
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
> > 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 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 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
|       | |
| "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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About