Thread: Re: [Module::Build] Archive::Tar file format (Page 3)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Randy W. S. <Ra...@Th...> - 2004-01-08 00:11:08
Attachments:
Build.PL
|
On 1/7/2004 5:47 PM, Glenn Linderman wrote: > On approximately 1/7/2004 1:08 AM, came the following characters from > the keyboard of Jos I. Boumans: > >> >> On 7-jan-04, at 3:35, Glenn Linderman wrote: >> >>> The way I see things, after installing the A::T 1.07 on Windows >>> (hadn't notice 1.08 yet, Randy has sharp eyes!), I would use M::B to >>> build a module's .tar.gz and .ppd file, and then there were 3 >>> symptoms, that may or may not be related. >>> >>> 1) During the build of the .tar.gz, warnings were printed about not >>> being able to add directory entries to the archive. >> >> >> by A::T? if so, can you provide me with a test case? > > > Using Win2K SP4, M::B 21_02, A::T 1.07 (latest with PPDs in my > repository list) If the ppm archives are not up to date yet, and you don't have a make tool, grab A::T 1.08 from CPAN.org and put the attached 'Build.PL' in the root distribution dir, and you should be able to use it to install. > Unzip the attached (Actually, I'll send it to you privately), will > create \GFfP directory structure. > > cd \GFfP > perl build.pl > perl build > perl build dist > > Warnings from the last command are: > > d:\GFfP>perl build dist > perl build dist > Unable to add file: 'GFfP-0.1' at C:\Perl\site\lib/Module/Build/Base.pm > line 1706 > Unable to add file: 'GFfP-0.1/blib' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/lib' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/arch' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/arch/auto' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/arch/auto/GFfP' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Deleting META.yml > Creating GFfP-0.1.tar.gz > Deleting GFfP-0.1 This is fixed in 1.08. >>> 2) Most TAR decoding programs cannot see the PATH data, although the >>> latest GNU TAR can >> >> >> yes, apparently (especially on windows) there's many clients that >> follow an old(er) spec. Although i am still of the same opinion that >> these clients are just inherintly broken, I do have a thought on how >> we may be able to amend this; >> >> Can one of you who had trouble with the extracting confirm that when >> extracting this tarball >> >> http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- >> Pluggable-Module-SimpleBlog-0.02.tar.gz > > > Well, interesting. > > PowerArchiver 2001 can usually ungzip and untar in one operation. But > not this file. But by first doing ungzip in PowerArchiver, and then > reopening the resulting .tar file in PowerArchiver, then the paths are > visible. I tested with WinZip 8.1 and WinRAR 3.20 and both worked, I had forgot you had mentioned the problem occuring in PowerArchiver. >> everything actually goes as expected, and that a file named >> >> Bot-BasicBot-Pluggable-Module-SimpleBlog-0.02/lib/Bot/BasicBot/ >> Pluggable/Module/SimpleBlog/Store/SQLite.pm >> >> is living in the extracted directory? > > > In the extracted directory, at the location specified, there is a file > named "SQ" which seems to contain what you would expect to find in a > file named SQLite.pm . So it appears that PowerArchiver 2001 length > limits the extraction path name to a length of 100 bytes. > > However, the "unxutils" version of TAR can extract it, some other > ancient NT port of TAR can extract it. GNU TAR 1.12 can extract it. > > None of these latter three utilities can extract the path names of the > .tar.gz build for the attached module, by A::T 1.07 (nor can > PowerArchiver 2001). > >> If so, we could use the ././@LongLink extended tar format solution, >> which is >> really meant to be used for paths > 255 chars, but will work equally >> well for >> our purposes here... i'd equip A::T with a special flag that would >> trigger the >> use of ././@LongLink files at anything over >100 chars, rather than >> at >255, >> thus avoiding the use of the PREFIX header, and thus (hopefully) >> solving your >> problems :) > > > As far as avoiding the problems, I don't think any of my paths are > greater than 100 chars. They are less. But still not seen by the above > mentioned 4 programs. > >>> 3) PPM claims to install the module, but nothing actually gets >>> installed. M::B can install the module fine from the source >>> directory. Given the other symptoms, it seems like it can't find >>> the files in the archive, but it reports no errors. >> >> >> not much i can do with this one > > > Well, if PPM is using A::T to do extraction (I believe it is), and I am > using A::T to do archiving (I believe M::B is, on my behalf), and PPM > cannot extract the files because of a either a change in A::T interface, > or a change in A::T file format, then perhaps you can, as you maintain > A::T. On the other hand, if PPM is misusing A::T, then you probably can't. > > I really don't know where the problem is, for this one, but if we can > get the first two issues resolved, then we will have a better foundation > on which to analyze this third issue. And get the PPM folks involved if > needed. But it is hard to point the finger at PPM at the moment, since > (1) It hasn't changed (on my machine, at least) (2) It unpacks lots of > other stuff (3) just the .tar.gz package build by M::B and A::T seem to > give it problems. Randy. |
|
From: Glenn L. <pe...@ne...> - 2004-01-08 02:50:50
|
On approximately 1/7/2004 4:10 PM, came the following characters from the keyboard of Randy W. Sims: > On 1/7/2004 5:47 PM, Glenn Linderman wrote: > >> On approximately 1/7/2004 1:08 AM, came the following characters from >> the keyboard of Jos I. Boumans: >> >>> >>> On 7-jan-04, at 3:35, Glenn Linderman wrote: >>> >>>> The way I see things, after installing the A::T 1.07 on Windows >>>> (hadn't notice 1.08 yet, Randy has sharp eyes!), I would use M::B >>>> to build a module's .tar.gz and .ppd file, and then there were 3 >>>> symptoms, that may or may not be related. >>>> >>>> 1) During the build of the .tar.gz, warnings were printed about not >>>> being able to add directory entries to the archive. >>> >>> >>> >>> by A::T? if so, can you provide me with a test case? >> >> >> >> Using Win2K SP4, M::B 21_02, A::T 1.07 (latest with PPDs in my >> repository list) > > > If the ppm archives are not up to date yet, and you don't have a make > tool, grab A::T 1.08 from CPAN.org and put the attached 'Build.PL' in > the root distribution dir, and you should be able to use it to install. > >> Unzip the attached (Actually, I'll send it to you privately), will >> create \GFfP directory structure. >> >> cd \GFfP >> perl build.pl >> perl build >> perl build dist >> >> Warnings from the last command are: >> >> d:\GFfP>perl build dist >> perl build dist >> Unable to add file: 'GFfP-0.1' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/lib' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/arch' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/arch/auto' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/arch/auto/GFfP' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Deleting META.yml >> Creating GFfP-0.1.tar.gz >> Deleting GFfP-0.1 > > > This is fixed in 1.08. OK, I've installed Archive::Tar 1.08, and confirmed that I no longer get the warnings above. >>>> 2) Most TAR decoding programs cannot see the PATH data, although >>>> the latest GNU TAR can >>> >>> >>> >>> yes, apparently (especially on windows) there's many clients that >>> follow an old(er) spec. Although i am still of the same opinion that >>> these clients are just inherintly broken, I do have a thought on how >>> we may be able to amend this; >>> >>> Can one of you who had trouble with the extracting confirm that when >>> extracting this tarball >>> >>> http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- >>> Pluggable-Module-SimpleBlog-0.02.tar.gz >> >> >> >> Well, interesting. >> >> PowerArchiver 2001 can usually ungzip and untar in one operation. But >> not this file. But by first doing ungzip in PowerArchiver, and then >> reopening the resulting .tar file in PowerArchiver, then the paths are >> visible. > > > I tested with WinZip 8.1 and WinRAR 3.20 and both worked, I had forgot > you had mentioned the problem occuring in PowerArchiver. Yep, well it seems pretty clear that PowerArchiver is truncating names longer than 100 chars. But my module's .tar.gz doesn't have names longer than 100 chars. But PowerArchiver still can't see the pathnames for my module, not even when built with A::T 1.08 (previous test was with 1.07). >>> everything actually goes as expected, and that a file named >>> >>> Bot-BasicBot-Pluggable-Module-SimpleBlog-0.02/lib/Bot/BasicBot/ >>> Pluggable/Module/SimpleBlog/Store/SQLite.pm >>> >>> is living in the extracted directory? >> >> >> >> In the extracted directory, at the location specified, there is a file >> named "SQ" which seems to contain what you would expect to find in a >> file named SQLite.pm . So it appears that PowerArchiver 2001 length >> limits the extraction path name to a length of 100 bytes. >> >> However, the "unxutils" version of TAR can extract it, some other >> ancient NT port of TAR can extract it. GNU TAR 1.12 can extract it. >> >> None of these latter three utilities can extract the path names of the >> .tar.gz build for the attached module, by A::T 1.07 (nor can >> PowerArchiver 2001). >> >>> If so, we could use the ././@LongLink extended tar format solution, >>> which is >>> really meant to be used for paths > 255 chars, but will work equally >>> well for >>> our purposes here... i'd equip A::T with a special flag that would >>> trigger the >>> use of ././@LongLink files at anything over >100 chars, rather than >>> at >255, >>> thus avoiding the use of the PREFIX header, and thus (hopefully) >>> solving your >>> problems :) >> >> >> >> As far as avoiding the problems, I don't think any of my paths are >> greater than 100 chars. They are less. But still not seen by the >> above mentioned 4 programs. >> >>>> 3) PPM claims to install the module, but nothing actually gets >>>> installed. M::B can install the module fine from the source >>>> directory. Given the other symptoms, it seems like it can't find >>>> the files in the archive, but it reports no errors. >>> >>> >>> >>> not much i can do with this one Randy... It looks like M::B 0.21_02 is still building PPD files that PPM dislikes: "Error: no suitable installation target found for package GFfP." So I still have to manually edit the PPD file to fix this. Maybe this one got dropped through the cracks of all the other problems? After hand editing the PPD file, this time around PPM install GFfP.ppd again claimed to installe GFfP, but only one file was listed during the install (hey, that's better than none, like last time around): ppm> install GFfP.ppd ==================== Install 'GFfP' version 0.1 in ActivePerl 5.8.0.805. ==================== Downloaded 7356 bytes. Extracting 14/14: GFfP-0.1/blib/arch/auto/GFfP/GFfP.lib Successfully installed GFfP version 0.1 in ActivePerl 5.8.0.805. And? It didn't actually install anything, not even that one file. So it still seems to me like PPM is getting confused by a funny .tar.gz file. Or something. >> Well, if PPM is using A::T to do extraction (I believe it is), and I >> am using A::T to do archiving (I believe M::B is, on my behalf), and >> PPM cannot extract the files because of a either a change in A::T >> interface, or a change in A::T file format, then perhaps you can, as >> you maintain A::T. On the other hand, if PPM is misusing A::T, then >> you probably can't. >> >> I really don't know where the problem is, for this one, but if we can >> get the first two issues resolved, then we will have a better >> foundation on which to analyze this third issue. And get the PPM >> folks involved if needed. But it is hard to point the finger at PPM >> at the moment, since (1) It hasn't changed (on my machine, at least) >> (2) It unpacks lots of other stuff (3) just the .tar.gz package build >> by M::B and A::T seem to give it problems. > > > Randy. > > > > > ------------------------------------------------------------------------ > > use Module::Build; > > use strict; > use warnings; > > my $have_zlib = eval { require IO::Zlib; 1 }; > > unless( $have_zlib ) { > warn <<EOM; > You do not have IO::Zlib installed. This means you can not read > or write compressed archives! > EOM > } > > Module::Build->new( > module_name => 'Module::Build', > dist_author => 'Jos Boumans <kane[at]cpan.org>', > dist_abstract => 'Manipulates TAR archives', > dist_version_from => 'lib/Archive/Tar.pm', > license => 'perl', > > requires => { > 'perl' => '5.005_03', > 'File::Spec' => 0.82, > }, > recommends => { > 'IO::Zlib' => 0, > }, > build_requires => { > 'Test::More' => 0, > 'Test::Harness' => 2.26, > }, > )->create_build_script(); > -- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing. |
|
From: Ken W. <ke...@ma...> - 2004-01-08 04:04:39
|
On Wednesday, January 7, 2004, at 08:51 PM, Glenn Linderman wrote: > Randy... It looks like M::B 0.21_02 is still building PPD files that > PPM dislikes: "Error: no suitable installation target found for > package GFfP." So I still have to manually edit the PPD file to fix > this. Maybe this one got dropped through the cracks of all the other > problems? Hmm, it may have - if you don't mind reminding me, what kind of edits did you have to make? -Ken |
|
From: Glenn L. <pe...@ne...> - 2004-01-08 05:05:22
|
On approximately 1/7/2004 8:04 PM, came the following characters from
the keyboard of Ken Williams:
> On Wednesday, January 7, 2004, at 08:51 PM, Glenn Linderman wrote:
>
>> Randy... It looks like M::B 0.21_02 is still building PPD files that
>> PPM dislikes: "Error: no suitable installation target found for
>> package GFfP." So I still have to manually edit the PPD file to fix
>> this. Maybe this one got dropped through the cracks of all the other
>> problems?
>
>
> Hmm, it may have - if you don't mind reminding me, what kind of edits
> did you have to make?
Well, now. I can tell you the edits I _did_ make, that cured the
symptom. Whether both were necessary, I couldn't say... but this made
it more like one that is "known to work".
diff -c gffp.ppd~ gffp.ppd
*** gffp.ppd~ Wed Jan 7 18:33:43 2004
--- gffp.ppd Wed Jan 7 18:41:38 2004
***************
*** 3,11 ****
<ABSTRACT>computational routines</ABSTRACT>
<AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR>
<IMPLEMENTATION>
- <PERLCORE VERSION="5,008000,0,0" />
<OS VALUE="MSWin32" />
! <ARCHITECTURE NAME="MSWin32-x86-multi-thread" />
<CODEBASE HREF="GFfP-0.1.tar.gz" />
</IMPLEMENTATION>
</SOFTPKG>
--- 3,10 ----
<ABSTRACT>computational routines</ABSTRACT>
<AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR>
<IMPLEMENTATION>
<OS VALUE="MSWin32" />
! <ARCHITECTURE NAME="MSWin32-x86-multi-thread-5.8" />
<CODEBASE HREF="GFfP-0.1.tar.gz" />
</IMPLEMENTATION>
</SOFTPKG>
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
|
|
From: Randy W. S. <Ra...@Th...> - 2004-01-08 05:04:27
Attachments:
PPMMaker.diff
|
On 1/7/2004 9:51 PM, Glenn Linderman wrote: > Randy... It looks like M::B 0.21_02 is still building PPD files that PPM > dislikes: "Error: no suitable installation target found for package > GFfP." So I still have to manually edit the PPD file to fix this. Maybe > this one got dropped through the cracks of all the other problems? Hi Glenn, Sorry, I forgot about that one. Can you try the attached patch and let me know if it works for you? I "borrowed" the code from PPM.pm for modifying the archname based on perl version >5.8. I also noticed that PPM uses NAME rather than VALUE in the OS tag and corrected it. Regards, Randy. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-08 05:15:32
|
On 1/8/2004 12:04 AM, Randy W. Sims wrote:
> +sub _varchname {
> +# copied from PPM.pm
> + my $varchname = $Config{archname};
> + # Append "-5.8" to architecture name for Perl 5.8 and later
> + if (length($^V) && ord(substr($^V,1)) >= 8) {
> + $varchname .= sprintf("-%d.%d", ord($^V), ord(substr($^V,1)));
> + }
> +}
Of course there should be a return $varchname at the end of that sub.
|
|
From: Glenn L. <pe...@ne...> - 2004-01-08 06:42:28
|
On approximately 1/7/2004 9:15 PM, came the following characters from
the keyboard of Randy W. Sims:
> On 1/8/2004 12:04 AM, Randy W. Sims wrote:
>
>> +sub _varchname {
>> +# copied from PPM.pm
>> + my $varchname = $Config{archname};
>> + # Append "-5.8" to architecture name for Perl 5.8 and later
>> + if (length($^V) && ord(substr($^V,1)) >= 8) {
>> + $varchname .= sprintf("-%d.%d", ord($^V), ord(substr($^V,1)));
>> + }
>> +}
>
>
> Of course there should be a return $varchname at the end of that sub.
So the patch.bat in Perl Power Tools 0.12 seemed to do the job... but
produced a bunch of funny warnings about printing to a NULL filehandle.
Anyway, diff -u on the results reproduced the original patch, so I
think it did the desired patching. Then I added the return, and rebuilt
the .ppd. Seems to be acceptable to PPM now.
OF course, PPM still doesn't do anything... this version didn't even
talk about file 14/14.
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
|
|
From: Ken W. <ke...@ma...> - 2004-01-09 18:01:47
|
On Wednesday, January 7, 2004, at 03:08 AM, Jos I. Boumans wrote: > > On 7-jan-04, at 3:35, Glenn Linderman wrote: > >> 2) Most TAR decoding programs cannot see the PATH data, although the >> latest GNU TAR can > > yes, apparently (especially on windows) there's many clients that > follow an old(er) spec. Although i am still of the same opinion that > these clients are just inherintly broken ... Let me reiterate that these clients are *NOT* IMO broken. They implement the TAR spec, at the time of their writing, correctly. The broken thing seems to be the updated TAR spec, which changed in such a way that any archive that uses the new features won't work with old clients. That's really a terrible thing to do to a "standard". -Ken |
|
From: Jos I. B. <ka...@dw...> - 2004-01-12 08:19:41
|
On 9-jan-04, at 19:01, Ken Williams wrote: > Let me reiterate that these clients are *NOT* IMO broken. They > implement the TAR spec, at the time of their writing, correctly. seeing the way the tar header is built up, i'd be terribly surprised if the prefix header field didn't exist all along... we can only speculate right now why or how it wasn't implemented in some of the other tools. The proposed @LongLink solutions seems to work for the 2 people on the cc list, so i'll try and build a snapshot that behaves accordingly... > The broken thing seems to be the updated TAR spec, which changed in > such a way that any archive that uses the new features won't work with > old clients. That's really a terrible thing to do to a "standard". yes it is,... especially if it's causing me extra work... ;) p.s. it's enough to send me every mail /once/ -- putting me both in to: and cc: is a bit overkill... p.p.s ken, could you maybe whitelist this mail address for the mb mailing list? getting slightly tired of the 'your message is being held for approval' mails.. -- Jos Boumans "We are not far from the kind of moral decay that has brought on the fall of other nations and peoples" - Senator Barry Goldwater, 1964 CPANPLUS http://cpanplus.sf.net |
|
From: Ken W. <ke...@ma...> - 2004-01-12 14:09:51
|
On Monday, January 12, 2004, at 02:19 AM, Jos I. Boumans wrote: > seeing the way the tar header is built up, i'd be terribly surprised > if the prefix header field didn't exist all along... we can only > speculate right now why or how it wasn't implemented in some of the > other tools. > The proposed @LongLink solutions seems to work for the 2 people on the > cc list, so i'll try and build a snapshot that behaves accordingly... Okay, let's see how that works - I thought there was a person who it didn't work so well for, though. > > p.s. it's enough to send me every mail /once/ -- putting me both in > to: and cc: is a bit overkill... Oopsie. > p.p.s ken, could you maybe whitelist this mail address for the mb > mailing list? getting slightly tired of the 'your message is being > held for approval' mails.. Gee, and I thought it was me getting tired of approving them... The way this is usually done is to subscribe to the list and then set yourself to "nomail". I've done this for your address. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-12-20 15:46:34
|
On Friday, December 19, 2003, at 04:05 AM, Randy W. Sims wrote: > > This is happening because M::B didn't find an abstract (this comes > from the pod, =head1 NAME section). I'm not sure, but in PPMMaker.pm > lines 22-25 I think all of these fields should be required (name, > author, abstract, version) and we should die with a usefull message if > not found. Ken? Agreed. > On 12/19/2003 4:30 AM, Glenn Linderman wrote: > >> This produces a pretty nice looking result, real corresponding to >> other .ppd files for other modules with similar requirements. But >> apparently there are a couple bugs in the build ppd that produce the >> warnings above. >> And so I'd like to see a "fix" to allow CODEBASE to default to the >> name of the .tar.gz file built by "build dist", and then people that >> want something more complex can still provide the command line >> override, or the build.pl file setting, or whatever. But the above >> type of PPD can be copied from spot to spot, together with keeping >> the .tar.gz in the same directory, and works great. > > Ok, I agree with this, with the caveat that M::B should print out an > informational message saying what it is using a default. Done. >> Yeah, they went away like magic, once YAML was installed. Just more >> dependency-itis to deal with. > > This still needs some kind of fix. If YAML is not available, M::B > should handle it more gracefully... > It's possible we could produce the META.yml without using YAML.pm, but the META.yml does need to be produced. At this point it's a real error not to have YAML.pm installed. -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-20 10:42:09
Attachments:
patch
|
This patch: * Moves documentation for the C<codebase> parameter to the section describing the ppd action. * Set C<codebase> to default to the distribution name with a '.tar.gz' extension. Notify user if the default is used. * Warn user to edit the produced PPD file if we can't determine values for name, version, and abstract. I will leave writing tutorials to someone with more literary talent than I :-) Regards, Randy. |
|
From: Ken W. <ke...@ma...> - 2003-12-20 16:25:00
|
Hi,
I applied the documentation part of the patch, but I had already
patched the other stuff in a different way by the time I saw this. Is
it not good to simply die() when there's no version, abstract, or
author? Seems like those should be required.
-Ken
On Saturday, December 20, 2003, at 04:41 AM, Randy W. Sims wrote:
>
> This patch:
>
> * Moves documentation for the C<codebase> parameter to the section
> describing the ppd action.
>
> * Set C<codebase> to default to the distribution name with a '.tar.gz'
> extension. Notify user if the default is used.
>
> * Warn user to edit the produced PPD file if we can't determine values
> for name, version, and abstract.
>
>
> I will leave writing tutorials to someone with more literary talent
> than
> I :-)
>
> Regards,
> Randy.
>
>
> diff -urN Module-Build-orig/lib/Module/Build/PPMMaker.pm
> Module-Build/lib/Module/Build/PPMMaker.pm
> --- Module-Build-orig/lib/Module/Build/PPMMaker.pm 2003-07-25
> 10:15:19.000000000 -0400
> +++ Module-Build/lib/Module/Build/PPMMaker.pm 2003-12-20
> 04:56:36.000000000 -0500
> @@ -15,14 +15,23 @@
> my ($self, %args) = @_;
> my $build = delete $args{build};
>
> - die "Cannot create a PPD file unless codebase argument is given\n"
> - unless exists $args{codebase};
> - my @codebase = ref $args{codebase} ? @{$args{codebase}} :
> ($args{codebase});
> + my $name = $build->dist_name || '';
> + my $author = $build->dist_author || '';
> + my $abstract = $build->dist_abstract || '';
> + my $version = $self->_ppd_version($build->dist_version) || '';
> +
> + die "Cannot determine distribution name.\n" unless length($name);
> +
> + warn "Missing information for PPD. Please edit before
> distributing.\n"
> + unless length($author) && length($abstract) && length($version);
> +
> + unless (exists $args{codebase}) {
> + my $codebase = $build->dist_dir . '.tar.gz';
> + $args{codebase} = $codebase;
> + print "Using a default CODEBASE of '$codebase'\n";
> + }
>
> - my $name = $build->dist_name;
> - my $author = $build->dist_author;
> - my $abstract = $build->dist_abstract;
> - my $version = $self->_ppd_version($build->dist_version);
> + my @codebase = ref $args{codebase} ? @{$args{codebase}} :
> ($args{codebase});
>
> $self->_simple_xml_escape($_) foreach ($abstract, $author);
>
> diff -urN Module-Build-orig/lib/Module/Build.pm
> Module-Build/lib/Module/Build.pm
> --- Module-Build-orig/lib/Module/Build.pm 2003-12-09
> 21:36:45.000000000 -0500
> +++ Module-Build/lib/Module/Build.pm 2003-12-20 04:35:23.000000000
> -0500
> @@ -575,13 +575,6 @@
> version. It looks for the first line matching C<$package\s-\s(.+)>,
> and uses the captured text as the abstract.
>
> -=item codebase
> -
> -This can be either a single scalar string, or an array reference of
> -strings. It is required when creating PPD files. It should be a URL,
> -or URLs, to be used as the value for the C<< <CODEBASE> >> tag in the
> -generated PPD.
> -
> =back
>
> =item subclass()
> @@ -1212,6 +1205,15 @@
>
> Build a PPD file for your distribution.
>
> +This action takes an optional argument C<codebase> which is used in
> +the generated ppd file to specify the (usually relative) URL of the
> +distribution. By default, this value is the distribution name without
> +any path information.
> +
> +Example:
> +
> + perl Build ppd
> codebase="MSWin32-x86-multi-thread/Module-Build-0.21.tar.gz"
> +
> =back
>
> =head2 How Installation Paths are Determined
>
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-20 16:50:09
|
On 12/20/2003 11:23 AM, Ken Williams wrote: > Hi, > > I applied the documentation part of the patch, but I had already patched > the other stuff in a different way by the time I saw this. Is it not > good to simply die() when there's no version, abstract, or author? > Seems like those should be required. I wavered a bit when working on the patch. I definately think that a PPD file should not be released without all of the above information. I guess the only concern I have is if a module does something abnormal like putting the pod in a separate pod file, so that M::B doesn't find the abstract; at least the author could manually fix the PPD file. But, maybe it should just die, and if anyone runs into anything reasonably abnormal we can make the appropriate change. Randy. |
|
From: Dave R. <au...@ur...> - 2003-12-20 17:17:50
|
On Sat, 20 Dec 2003, Randy W. Sims wrote: > I wavered a bit when working on the patch. I definately think that a PPD > file should not be released without all of the above information. I > guess the only concern I have is if a module does something abnormal > like putting the pod in a separate pod file, so that M::B doesn't find > the abstract; at least the author could manually fix the PPD file. But, > maybe it should just die, and if anyone runs into anything reasonably > abnormal we can make the appropriate change. I think it would be better to die and then add code to accomodate this. For example, we could do something like add a "ppd_info_file" constructor argument so that M::B would like there for the abstract & author info. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-12-20 19:58:24
|
On Saturday, December 20, 2003, at 10:49 AM, Randy W. Sims wrote: > On 12/20/2003 11:23 AM, Ken Williams wrote: > >> Hi, >> I applied the documentation part of the patch, but I had already >> patched the other stuff in a different way by the time I saw this. >> Is it not good to simply die() when there's no version, abstract, or >> author? Seems like those should be required. > > I wavered a bit when working on the patch. I definately think that a > PPD file should not be released without all of the above information. > I guess the only concern I have is if a module does something abnormal > like putting the pod in a separate pod file, so that M::B doesn't find > the abstract; at least the author could manually fix the PPD file. > But, maybe it should just die, and if anyone runs into anything > reasonably abnormal we can make the appropriate change. Currently it looks for the abstract & author in the same place as the version. If that's not proper, the author can actually just add a 'dist_abstract' and/or 'dist_author' parameter to the Build->new() method too. -Ken |
|
From: Glenn L. <pe...@ne...> - 2003-12-20 17:23:09
|
I'm no expert in the required contents of a .ppd file. But I can't
imagine ever wanting one that doesn't have a version. While it is nice
to also have the author and abstract, I can't see that having them or
not having them makes the module more or less functional.
On approximately 12/20/2003 8:23 AM, came the following characters from
the keyboard of Ken Williams:
> Hi,
>
> I applied the documentation part of the patch, but I had already patched
> the other stuff in a different way by the time I saw this. Is it not
> good to simply die() when there's no version, abstract, or author?
> Seems like those should be required.
>
> -Ken
>
>
> On Saturday, December 20, 2003, at 04:41 AM, Randy W. Sims wrote:
>
>>
>> This patch:
>>
>> * Moves documentation for the C<codebase> parameter to the section
>> describing the ppd action.
>>
>> * Set C<codebase> to default to the distribution name with a '.tar.gz'
>> extension. Notify user if the default is used.
>>
>> * Warn user to edit the produced PPD file if we can't determine values
>> for name, version, and abstract.
>>
>>
>> I will leave writing tutorials to someone with more literary talent than
>> I :-)
>>
>> Regards,
>> Randy.
>>
>>
>> diff -urN Module-Build-orig/lib/Module/Build/PPMMaker.pm
>> Module-Build/lib/Module/Build/PPMMaker.pm
>> --- Module-Build-orig/lib/Module/Build/PPMMaker.pm 2003-07-25
>> 10:15:19.000000000 -0400
>> +++ Module-Build/lib/Module/Build/PPMMaker.pm 2003-12-20
>> 04:56:36.000000000 -0500
>> @@ -15,14 +15,23 @@
>> my ($self, %args) = @_;
>> my $build = delete $args{build};
>>
>> - die "Cannot create a PPD file unless codebase argument is given\n"
>> - unless exists $args{codebase};
>> - my @codebase = ref $args{codebase} ? @{$args{codebase}} :
>> ($args{codebase});
>> + my $name = $build->dist_name || '';
>> + my $author = $build->dist_author || '';
>> + my $abstract = $build->dist_abstract || '';
>> + my $version = $self->_ppd_version($build->dist_version) || '';
>> +
>> + die "Cannot determine distribution name.\n" unless length($name);
>> +
>> + warn "Missing information for PPD. Please edit before distributing.\n"
>> + unless length($author) && length($abstract) && length($version);
>> +
>> + unless (exists $args{codebase}) {
>> + my $codebase = $build->dist_dir . '.tar.gz';
>> + $args{codebase} = $codebase;
>> + print "Using a default CODEBASE of '$codebase'\n";
>> + }
>>
>> - my $name = $build->dist_name;
>> - my $author = $build->dist_author;
>> - my $abstract = $build->dist_abstract;
>> - my $version = $self->_ppd_version($build->dist_version);
>> + my @codebase = ref $args{codebase} ? @{$args{codebase}} :
>> ($args{codebase});
>>
>> $self->_simple_xml_escape($_) foreach ($abstract, $author);
>>
>> diff -urN Module-Build-orig/lib/Module/Build.pm
>> Module-Build/lib/Module/Build.pm
>> --- Module-Build-orig/lib/Module/Build.pm 2003-12-09
>> 21:36:45.000000000 -0500
>> +++ Module-Build/lib/Module/Build.pm 2003-12-20 04:35:23.000000000
>> -0500
>> @@ -575,13 +575,6 @@
>> version. It looks for the first line matching C<$package\s-\s(.+)>,
>> and uses the captured text as the abstract.
>>
>> -=item codebase
>> -
>> -This can be either a single scalar string, or an array reference of
>> -strings. It is required when creating PPD files. It should be a URL,
>> -or URLs, to be used as the value for the C<< <CODEBASE> >> tag in the
>> -generated PPD.
>> -
>> =back
>>
>> =item subclass()
>> @@ -1212,6 +1205,15 @@
>>
>> Build a PPD file for your distribution.
>>
>> +This action takes an optional argument C<codebase> which is used in
>> +the generated ppd file to specify the (usually relative) URL of the
>> +distribution. By default, this value is the distribution name without
>> +any path information.
>> +
>> +Example:
>> +
>> + perl Build ppd
>> codebase="MSWin32-x86-multi-thread/Module-Build-0.21.tar.gz"
>> +
>> =back
>>
>> =head2 How Installation Paths are Determined
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
>
>
--
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick. It's ridiculous.
-- Bill Gates
And here is why it is ridiculous:
The division that includes Windows posted an operating profit of $2.26
billion on revenue of $2.81 billion.
--from Reuters via
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html
So that's profit of over 400% of investment... with a bit more
investment in Windows technology, particularly in the area of
reliability, the profit percentage might go down, but so might the bugs
and security problems? Seems like it would be a reasonable tradeoff.
WalMart earnings are 3.4% of investment.
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-20 17:41:39
|
On 12/20/2003 12:17 PM, Glenn Linderman wrote: > I'm no expert in the required contents of a .ppd file. But I can't > imagine ever wanting one that doesn't have a version. While it is nice > to also have the author and abstract, I can't see that having them or > not having them makes the module more or less functional. Those fields are not required for a PPD file. It's been a long time since I've used ppm, but I recall seeing more than a few without abstracts and other info. But, I think it is more than reasonable to require this information. Browsing thruough several screens of module names (many of which are unhelpfully named to say the least) trying to figure out what each module does is a pain and a waste of time. An author name should also be required in case there are problems with the module or the distribution. Name and version are obvious requirements. Besides even if it was decided to not require this info for the PPD, it would still need to be required for the META.yml files, thus the info would be there anyway. :-) Regards, Randy. |
Thanks for helping keep SourceForge clean.
X