Thread: Re: [Module::Build] codebase? paths in .tar.gz? (Page 2)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Glenn L. <pe...@ne...> - 2003-12-22 01:46:02
|
On approximately 12/21/2003 5:31 PM, came the following characters from the keyboard of Glenn Linderman: > On approximately 12/21/2003 4:29 AM, came the following characters from > the keyboard of Jos I. Boumans: > >> >> On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote: >> >>> At the cost of making the A::T code somewhat ugly, I think an imperfect >>> heuristic solution is possible, so that if all PATHs in the tarball were >>> less than 100 characters in length, A::T could write the whole path at >>> the front of the chunk and not use the 'prefix' field -- with a >>> different >>> code path, using the 'prefix' field, followed if any path in the tarball >>> exceeds 100 characters in length. >> >> >> i'm very much opposed to this solution, since this still doesn't actually >> /fix/ the problem; it's merely coding around a problem in /other/ tools, >> and it will introduce a very fun /new/ 'bug' that distributions that keep >> their longest path under 100 chars will do the right thing, and any >> distribution with a path > 100 chars will now break... id much rather >> document this shortcoming in other tools and add a dependency on a >> /proper/ tar extractor, that follows the specs for the tar format... >> A::T, >> gnu tar and quite a few others do... old bsd tars and some )"(#/"#) >> windows tools dont..... >> >> just my $0.02 >> >> -jos > > > Interesting point of view. That's sort of like outlawing all the old > cars that don't have some new safety feature, making it illegal to drive > them on the roads. > > Sure seems to me that a high percentage of the tarballs in the world > have mostly paths less than 100 characters. > > It is too bad that the old programs can look at the new tarball and see > a subset of the data, instead of reporting the real condition, at least > as a warning if not an error: "This tarball was produced using a version > of tar that implements a newer specification than this tar program. To > see the tarball in its full detail, you should use a tar program that > implements specification GHI. This tar program only implements > specification ABC." > > That would explain the situation to the user. > > On the other hand, for those tarballs that can be correctly created > according to the older specifications, without loss of functionality, > that is an extremely friendly feature even for a program that is capable > of creating tarballs using the new specifications, with new > functionality. This sort of thing is called "backward compatibility", > and it encourages people to use the new program, since it interoperates > with the old, instead of encouraging them to throw the new program away, > sticking with the old tried and true and interoperable programs. > > I have to admit that if I was under time pressure today to release my > new module (I still have a few weeks to go), that I would be extremely > tempted to discard both > > (1) Archive::Tar, > (2) Module::Build, > > because > > (A) the module that I built won't install properly using PPM (even > with A::T v1.07), > (B) I can't see the paths to the files using PowerArchiver 2001, > (C) I don't get warnings for each directory that is supposed to be in > the tarball, and (C) is supposed to read "I _do_ get warnings..." or maybe just "I get warnings..." > (D) I have other sample modules using MakeMaker and tar programs, > that do not suffer from (A), (B), and (C), so it is clearly a functional > path to take. > > Since I have some lead time, I'll wait and see how this plays out over > the next few weeks. People like backward compatibility, because it > makes things work. And when things don't work, because of incremental > versionitis, it is nice if there is a built in method for reporting that > that is why, instead of simply providing reduced functionality without > warning. Providing reduced functionality is OK, with the warning. So > if an old tar program can extract the data, but not put it in the right > place, that is OK, if it tells me that it the tarball is a newer version > that it might not be able to fully decode. > > The fact that there are bugs and deficiencies in old programs, however, > is no excuse for a new program not to be as backward compatible as it > can be. > > Personally, I'd rather see archives stored as .zip files, which at least > were designed to do both archiving and compression in one step, rather > than play the two-step jig of .tar.gz. But that's a whole 'nother > story, and an idea which probably won't get much momentum or attention, > because .tar.gz is there and works. Well, given my above woes, sort of. > -- 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: Glenn L. <pe...@ne...> - 2003-12-22 01:22:37
|
On approximately 12/21/2003 4:18 AM, came the following characters from the keyboard of Andrew Savige: > --- "Randy W. Sims" <Ra...@Th...> wrote: > >>On 12/20/2003 5:23 PM, Jos I. Boumans wrote: >> >>>On Sat, 20 Dec 2003, Ken Williams wrote: >>> >>> >>>>On Saturday, December 20, 2003, at 12:17 PM, Randy W. Sims wrote: >>>> >>>> >>>>>Well this atleast proves that the paths are there, thus it is not a >>>>>problem with M::B, but I think this is going to be a big issue for >>>>>Windows users. I think if it's possible for Archive::Tar to be better >>>>>compatible with other tools, it should. If I knew anything about the >>>>>tar format, I'd try to provide a patch. Since I don't, I'll just cc >>>>>the maintainer. ;-) >>>> >>>>I have some kind of vague recollection that maybe this issue in >>>>Archive::Tar has been fixed privately by Kane and is just waiting for >>>>him to release it. >>>> >>>>Kane, can you put Glenn out of his misery? Or am I remembering wrong? >>> >>> >>>well, even though m::b may use A::T to build an archive, and ppm uses it >>>to extract, it may not be the same A::T -- AS perl ships with a very old >>>version of A::T which does not support the full tar standard (including >>>the prefix header). Several people have already advised AS to upgrade A::T >>>to a recent version, that works on win32 and actually supports most of the >>>spec... >>> >>>the easiest fix would be to require the client to have a::t > 1.00 to make >>>sure this doesn't happen, but i'm not sure how to enforce this... >> >>Hi Jos, >> >>Actually this problem is occuring in recent versions of Archive::Tar; In >>fact, it happens with a post 1.07 snapshot Andrew referred me to a while >>back when we were having other problems (warnings when directories are >>added to the tar). If Ken can confirm that he used 'perl Build dist' to >>create the 'Module-Build-0.21_01.tar.gz' dist currently on CPAN and that >>he used a recent version of Archive::Tar, I think that will narrow down >>the problem to something in the way tar files are created on Windows as >>opposed to other OSs. When I look at that dist in WinZip (one of the >>common programs on windows used to handle tar files), the directory >>structure is there. When I untar that dist and run 'perl Build dist' in >>it, the tar file created on Windows does not show the directory >>structure (although it is there as confirmed by some ported versions of >>gnu tar). So, the problem seems to be in the creation process on Windows... > > > Sorry, I've been too busy lately and haven't been following this thread > as closely as I should. One thing you should be aware of is trouble > ticket 4437 at: > http://rt.cpan.org/NoAuth/Bugs.html?Dist=Archive-Tar&ShowAll=1 > As discussed in detail in this thread, tarballs created by Archive::Tar > lose the directory information when unpacked/viewed with old versions of > tarball viewers/extractors that do not properly implement the latest tar > spec. IIRC, old versions of BSD tar and many versions of WinZip lose the > directory information. > > At the cost of making the A::T code somewhat ugly, I think an imperfect > heuristic solution is possible, so that if all PATHs in the tarball were > less than 100 characters in length, A::T could write the whole path at > the front of the chunk and not use the 'prefix' field -- with a different > code path, using the 'prefix' field, followed if any path in the tarball > exceeds 100 characters in length. AHA! This sounds like a comment from an expert in A::T! or at least in the changes to the tar spec over time! I appreciate the enlightenment it gives. So I can at least get a glimmering of understanding about the issue... I can infer from what was said that: * Old tar limited path names to 100 characters or less * New systems permit more than that (even old system permit more than that) * New tar implements new scheme for longer path names * Old tar programs don't understand the new scheme, and show file names only * For compatibility with the old programs and old specs, new programs could use the old scheme if the path names are less than 100 characters, which would work for many archives, actually. Sounds like a good idea to me. -- 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: Jos I. B. <ka...@dw...> - 2003-12-21 12:08:29
|
On Sun, 21 Dec 2003, Randy W. Sims wrote: > Actually this problem is occuring in recent versions of Archive::Tar; In > fact, it happens with a post 1.07 snapshot Andrew referred me to a while > back when we were having other problems (warnings when directories are > added to the tar). If Ken can confirm that he used 'perl Build dist' to > create the 'Module-Build-0.21_01.tar.gz' dist currently on CPAN and that > he used a recent version of Archive::Tar, I think that will narrow down > the problem to something in the way tar files are created on Windows as > opposed to other OSs. When I look at that dist in WinZip (one of the > common programs on windows used to handle tar files), the directory > structure is there. When I untar that dist and run 'perl Build dist' in > it, the tar file created on Windows does not show the directory > structure (although it is there as confirmed by some ported versions of > gnu tar). So, the problem seems to be in the creation process on Windows... hmm, well it would be good if you could make a small test case on win32 that demonstrates this problem (one file, one dir kind of thing), so i can investigate the tar file and see what goes wrong... |
|
From: Ken W. <ke...@ma...> - 2003-12-21 16:33:02
|
On Sunday, December 21, 2003, at 02:39 AM, Randy W. Sims wrote: > If Ken can confirm that he used 'perl Build dist' to create the > 'Module-Build-0.21_01.tar.gz' dist currently on CPAN and that he used > a recent version of Archive::Tar, Well, I built it on OS X, and on Unixish platforms Module::Build will just use an external call to the 'tar' command. So Archive::Tar wasn't in the mix. -Ken |
|
From: Jos I. B. <ka...@dw...> - 2003-12-20 22:22:52
|
On Sat, 20 Dec 2003, Ken Williams wrote: > On Saturday, December 20, 2003, at 12:17 PM, Randy W. Sims wrote: > > > > Well this atleast proves that the paths are there, thus it is not a > > problem with M::B, but I think this is going to be a big issue for > > Windows users. I think if it's possible for Archive::Tar to be better > > compatible with other tools, it should. If I knew anything about the > > tar format, I'd try to provide a patch. Since I don't, I'll just cc > > the maintainer. ;-) > > I have some kind of vague recollection that maybe this issue in > Archive::Tar has been fixed privately by Kane and is just waiting for > him to release it. > > Kane, can you put Glenn out of his misery? Or am I remembering wrong? well, even though m::b may use A::T to build an archive, and ppm uses it to extract, it may not be the same A::T -- AS perl ships with a very old version of A::T which does not support the full tar standard (including the prefix header). Several people have already advised AS to upgrade A::T to a recent version, that works on win32 and actually supports most of the spec... the easiest fix would be to require the client to have a::t > 1.00 to make sure this doesn't happen, but i'm not sure how to enforce this... -jos |
|
From: Glenn L. <pe...@ne...> - 2003-12-21 01:57:04
|
On approximately 12/20/2003 2:23 PM, came the following characters from the keyboard of Jos I. Boumans: > > On Sat, 20 Dec 2003, Ken Williams wrote: > >>On Saturday, December 20, 2003, at 12:17 PM, Randy W. Sims wrote: >> >>>Well this atleast proves that the paths are there, thus it is not a >>>problem with M::B, but I think this is going to be a big issue for >>>Windows users. I think if it's possible for Archive::Tar to be better >>>compatible with other tools, it should. If I knew anything about the >>>tar format, I'd try to provide a patch. Since I don't, I'll just cc >>>the maintainer. ;-) >> >>I have some kind of vague recollection that maybe this issue in >>Archive::Tar has been fixed privately by Kane and is just waiting for >>him to release it. >> >>Kane, can you put Glenn out of his misery? Or am I remembering wrong? > > > well, even though m::b may use A::T to build an archive, and ppm uses it > to extract, it may not be the same A::T -- AS perl ships with a very old > version of A::T which does not support the full tar standard (including > the prefix header). Several people have already advised AS to upgrade A::T > to a recent version, that works on win32 and actually supports most of the > spec... > > the easiest fix would be to require the client to have a::t > 1.00 to make > sure this doesn't happen, but i'm not sure how to enforce this... Well, I had to upgrade Archive::Tar to get Module::Build to work. Can ppm still use an older version after I've installed a new one? C:\Documents and Settings\Glenn>ppm PPM - Programmer's Package Manager version 3.0.1. Copyright (c) 2001 ActiveState SRL. All Rights Reserved. Entering interactive shell. Using Term::ReadLine::Stub as readline library. Profile tracking is not enabled. If you save and restore profiles manually, your profile may be out of sync with your computer. See 'help profile' for more information. Type 'help' to get started. ppm> query Archive Querying target 1 (ActivePerl 5.8.0.805) 1. Archive-Tar [1.07] Manipulates TAR archives 2. Archive-Zip [1.06] Provide an interface to ZIP archive files. ppm> exit -- 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...> - 2004-01-07 01:16:53
|
On 12/20/2003 5:23 PM, Jos I. Boumans wrote: > > On Sat, 20 Dec 2003, Ken Williams wrote: > >>On Saturday, December 20, 2003, at 12:17 PM, Randy W. Sims wrote: >> >>>Well this atleast proves that the paths are there, thus it is not a >>>problem with M::B, but I think this is going to be a big issue for >>>Windows users. I think if it's possible for Archive::Tar to be better >>>compatible with other tools, it should. If I knew anything about the >>>tar format, I'd try to provide a patch. Since I don't, I'll just cc >>>the maintainer. ;-) >> >>I have some kind of vague recollection that maybe this issue in >>Archive::Tar has been fixed privately by Kane and is just waiting for >>him to release it. >> >>Kane, can you put Glenn out of his misery? Or am I remembering wrong? > > > well, even though m::b may use A::T to build an archive, and ppm uses it > to extract, it may not be the same A::T -- AS perl ships with a very old > version of A::T which does not support the full tar standard (including > the prefix header). Several people have already advised AS to upgrade A::T > to a recent version, that works on win32 and actually supports most of the > spec... > > the easiest fix would be to require the client to have a::t > 1.00 to make > sure this doesn't happen, but i'm not sure how to enforce this... Hi Jos, I just saw that A::T 1.08 hit CPAN and was very quick to try it out. It's looking a lot better since you've taken over maintenance on it, and more specifically this latest release has fixed some annoying problems on Win32. However the above problem is unfortunately still present. I've verified that using this latest version to create an archive does not solve the problem with most Windows utilities being unable to read the path information in the archive. This problem does not occur with archive created with GNU tar. As this problem has been reported several times on the M::B mailing list (and is apparently becoming a critical issue for Win32 M::B users), I'm afraid this problem is going to continue to plague us unless we can find a resolution. If I knew anything of the tar format I'd submit a patch--Is there anything I can do to help resolve this issue. Thanks, Randy. |
|
From: Glenn L. <pe...@ne...> - 2004-01-07 02:35:02
|
On approximately 1/6/2004 5:16 PM, came the following characters from the keyboard of Randy W. Sims: > On 12/20/2003 5:23 PM, Jos I. Boumans wrote: > >> >> On Sat, 20 Dec 2003, Ken Williams wrote: >> >>> On Saturday, December 20, 2003, at 12:17 PM, Randy W. Sims wrote: >>> >>>> Well this atleast proves that the paths are there, thus it is not a >>>> problem with M::B, but I think this is going to be a big issue for >>>> Windows users. I think if it's possible for Archive::Tar to be better >>>> compatible with other tools, it should. If I knew anything about the >>>> tar format, I'd try to provide a patch. Since I don't, I'll just cc >>>> the maintainer. ;-) >>> >>> >>> I have some kind of vague recollection that maybe this issue in >>> Archive::Tar has been fixed privately by Kane and is just waiting for >>> him to release it. >>> >>> Kane, can you put Glenn out of his misery? Or am I remembering wrong? >> >> >> >> well, even though m::b may use A::T to build an archive, and ppm uses it >> to extract, it may not be the same A::T -- AS perl ships with a very old >> version of A::T which does not support the full tar standard (including >> the prefix header). Several people have already advised AS to upgrade >> A::T >> to a recent version, that works on win32 and actually supports most of >> the >> spec... >> >> the easiest fix would be to require the client to have a::t > 1.00 to >> make >> sure this doesn't happen, but i'm not sure how to enforce this... > > > Hi Jos, > > I just saw that A::T 1.08 hit CPAN and was very quick to try it out. > It's looking a lot better since you've taken over maintenance on it, and > more specifically this latest release has fixed some annoying problems > on Win32. However the above problem is unfortunately still present. I've > verified that using this latest version to create an archive does not > solve the problem with most Windows utilities being unable to read the > path information in the archive. This problem does not occur with > archive created with GNU tar. As this problem has been reported several > times on the M::B mailing list (and is apparently becoming a critical > issue for Win32 M::B users), I'm afraid this problem is going to > continue to plague us unless we can find a resolution. If I knew > anything of the tar format I'd submit a patch--Is there anything I can > do to help resolve this issue. > > Thanks, > Randy. Right. Thanks Randy for following up on this, I was just wondering again today if anything had happened in the last couple weeks (of course it is hard to get computer time during the holidays!). 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. 2) Most TAR decoding programs cannot see the PATH data, although the latest GNU TAR can 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. -- 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: Jos I. B. <ka...@dw...> - 2004-01-07 09:09:07
|
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? > 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 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? 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 :) > 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 -- Jos Boumans "If superman is so smart, why does he wear underpants over his trousers?" CPANPLUS http://cpanplus.sf.net |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-07 10:25:52
|
On 1/7/2004 4:08 AM, Jos I. Boumans wrote: > > 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? If this is what Glenn reported before, it was fixed in A::T 1.08. From the README: - Fix a bug where adding dirs on win32 gave 'permission denied' >> 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 > > 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? YES! Looks good. I will test more extensively when a snapshot is available. Thanks. > 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 :) > >> 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 I believe this might be related to #2 above, but I have not actually investigated as I don't normally use ppm. When a snapshot of the fixed A::T is available, I'll check it out and atleast notify someone on the ppm mailing list if it persists. Thanks, Randy. |
|
From: Jos I. B. <ka...@dw...> - 2004-01-12 11:15:56
Attachments:
Archive-Tar-1.08_01.tar.gz
|
> YES! Looks good. I will test more extensively when a snapshot is > available. Thanks. You can find a snapshot attached. To use the new feature, follow this bit of documentation: =head2 $Archive::Tar::DO_NOT_USE_PREFIX By default, C<Archive::Tar> will try to put paths that are over 100 characters in the C<prefix> field of your tar header. However, some older tar programs do not implement this spec. To retain compatibillity with these older versions, you can set the C<$DO_NOT_USE_PREFIX> variable to a true value, and C<Archive>>Tar> will use an alternate way of dealing with paths over 100 characters by using the C<GNU Extended Header> feature. The default is C<0>. On the discussion of what use of prefix is appropriate, etc, here's a relevant part from the gnu tar manual, found at: http://www.gnu.org/software/tar/manual/html_mono/tar.html#SEC112 >>>> Traditionally, old tars have a limit of 100 characters. GNU tar attempted two different approaches to overcome this limit, using and extending a format specified by a draft of some P1003.1. The first way was not that successful, and involved `@MaNgLeD@' file names, or such; while a second approach used `././@LongLink' and other tricks, yielding better success. In theory, GNU tarshould be able to handle file names of practically unlimited length. So, if GNU tar fails to dump and retrieve files having more than 100 characters, then there is a bug in GNU tar, indeed. But, being strictly POSIX, the limit was still 100 characters. For various other purposes, GNU tar used areas left unassigned in the POSIX draft. POSIX later revised P1003.1 ustar format by assigning previously unused header fields, in such a way that the upper limit for file name length was raised to 256 characters. However, the actual POSIX limit oscillates between 100 and 256, depending on the precise location of slashes in full file name (this is rather ugly). Since GNU tar use the same fields for quite other purposes, it became incompatible with the latest POSIX standards. <<<<< it's striking to note that most popular (windows) tools do implement one of the features, (././@LongLink), but not the other (PREFIX header use). Just for the record btw, A::T created tarfiles do identify themselves as 'ustar' files... let me know how you fare with this snapshot -- if it meets your needs, i'll release it as 1.09 asap. -- Jos Boumans "I speak better English than this villain Bush" - Muhammed Saeed al-Sahaf CPANPLUS http://cpanplus.sf.net |
|
From: Glenn L. <pe...@ne...> - 2004-01-12 18:38:10
|
On approximately 1/12/2004 3:15 AM, came the following characters from the keyboard of Jos I. Boumans: >> YES! Looks good. I will test more extensively when a snapshot is >> available. Thanks. > > > You can find a snapshot attached. To use the new feature, follow this > bit of documentation: > > =head2 $Archive::Tar::DO_NOT_USE_PREFIX Well, I still don't understand why all the discussion is about TAR files with paths greater than 100 characters, although that seems to be technical impetus for some of the changes to the TAR file format. My TAR file has only paths less than 100 characters. But still, this process doesn't work... While at the end, ppm claims to have install GFfP, none of the files have actually been installed. Along the way, PowerArchiver 2001 isn't able to see the pathnames. I see a bunch of new messages about "make longlink? 0 0" during the build of the TAR file; maybe I need a newer version of Module::Build to turn on the new option in Archive::Tar? Maybe the message is just a debugging message to see if M::B actually turned on the option? Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. d:\GFfP>perl -MArchive::Tar -e "print $Archive::Tar::VERSION" 1.08_01 d:\GFfP>perl -v perl -v This is perl, v5.8.0 built for MSWin32-x86-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2002, Larry Wall Binary build 805 provided by ActiveState Corp. http://www.ActiveState.com Built 18:08:02 Feb 4 2003 Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. d:\GFfP>perl build.pl Checking whether your kit is complete... Warning: the following files are missing in your kit: blib/arch/auto/GFfP/GFfP.bs blib/arch/auto/GFfP/GFfP.dll blib/arch/auto/GFfP/GFfP.exp blib/arch/auto/GFfP/GFfP.lib blib/lib/GFfP.pm Please inform the author. Creating new 'Build' script for 'GFfP' version '0.1' d:\GFfP>perl build lib\GFfP.pm -> blib\lib\GFfP.pm lib\GFfP.xs -> lib\GFfP.c C:\Perl\bin\perl.exe "-IC:\Perl\lib" "-IC:\Perl\lib" "C:\Perl\lib\ExtUtils\xsubpp" -noprototypes -typemap "C:\Perl\lib\ExtUtils\typemap" "lib\GFfP.xs"Generating script 'lib\GFfP.ccs' cl -c @"lib\GFfP.ccs" -Fo"lib\GFfP.obj" "lib\GFfP.c" GFfP.c ExtUtils::Mkbootstrap::Mkbootstrap('lib\GFfP') ExtUtils::Mksymlists::Mksymlists('lib\GFfP') Generating script 'lib\GFfP.lds' link @"lib\GFfP.lds" -out:"blib\arch\auto\GFfP\GFfP.dll" Creating library blib\arch\auto\GFfP\GFfP.lib and object blib\arch\auto\GFfP\GFfP.exp d:\GFfP>perl build dist Deleting META.yml Creating GFfP-0.1.tar.gz make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 make longlink? 0 0 Deleting GFfP-0.1 d:\GFfP>perl build ppd Using default codebase 'GFfP-0.1.tar.gz' d:\GFfP>dir *.gz Volume in drive D is my Volume Serial Number is F068-73C9 Directory of d:\GFfP 01/12/2004 10:27a 7,316 GFfP-0.1.tar.gz 1 File(s) 7,316 bytes 0 Dir(s) 19,563,614,208 bytes free d:\GFfP>ppm install GFfP.ppd ==================== Install 'GFfP' version 0.1 in ActivePerl 5.8.0.805. ==================== Successfully installed GFfP version 0.1 in ActivePerl 5.8.0.805. d:\GFfP> -- 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 K. <ra...@th...> - 2004-01-12 21:23:00
|
On Mon, 12 Jan 2004, Glenn Linderman wrote: > d:\GFfP>perl build dist > Deleting META.yml > Creating GFfP-0.1.tar.gz [ ... ] > d:\GFfP>perl build ppd > Using default codebase 'GFfP-0.1.tar.gz' > > d:\GFfP>dir *.gz > > 01/12/2004 10:27a 7,316 GFfP-0.1.tar.gz > > d:\GFfP>ppm install GFfP.ppd > ==================== > Install 'GFfP' version 0.1 in ActivePerl 5.8.0.805. > ==================== > Successfully installed GFfP version 0.1 in ActivePerl 5.8.0.805. I think the problem here is that the 'dist' build target makes an archive suitable for CPAN, whereas the archive that ppm expects (as specified by the codebase) is just an archive of the blib/ directory. Try perl build ppd tar cvf GFfP-0.1.tar blib gzip --best GFfP-0.1.tar ppm install GFfP.ppd -- best regards, randy |
|
From: Glenn L. <pe...@ne...> - 2004-01-12 22:26:20
|
On approximately 1/12/2004 1:20 PM, came the following characters from the keyboard of Randy Kobes: > On Mon, 12 Jan 2004, Glenn Linderman wrote: > > >>d:\GFfP>perl build dist >>Deleting META.yml >>Creating GFfP-0.1.tar.gz > > [ ... ] > >>d:\GFfP>perl build ppd >>Using default codebase 'GFfP-0.1.tar.gz' >> >>d:\GFfP>dir *.gz >> >>01/12/2004 10:27a 7,316 GFfP-0.1.tar.gz >> >>d:\GFfP>ppm install GFfP.ppd >>==================== >>Install 'GFfP' version 0.1 in ActivePerl 5.8.0.805. >>==================== >>Successfully installed GFfP version 0.1 in ActivePerl 5.8.0.805. > > > I think the problem here is that the 'dist' build target > makes an archive suitable for CPAN, whereas the archive > that ppm expects (as specified by the codebase) is just > an archive of the blib/ directory. Try > perl build ppd > tar cvf GFfP-0.1.tar blib > gzip --best GFfP-0.1.tar > ppm install GFfP.ppd Hmm. I don't know enough about CPAN or PPM to verify or contradict this speculation. I started using Module::Build because it seemed like it was supposed to be an easier way to build packages that MakeMaker. If what you say above is, indeed, correct and turns out to be "the problem", then it would seems that either Module::Build needs an additional target to build distributions for PPM, or else I missed understanding which target I should use when I read the Module::Build documentation. If a different .tar.gz file is the problem, I'd think it should be bundled into the perl build ppd command, such that that command builds the two files necessary to use with PPM. I don't have a solution or recommendation for the naming conflict that results from having two different .tar.gz files for two different purposes for the same module for CPAN vs PPM. Maybe the substrings "-CPAN" and "-PPM" should be added into the .tar.gz file name somewhere. The command sequence you offered above does, in fact, work. But I don't know enough to know if it is because I am using a different version of TAR (not Archive::Tar), or because there are fewer files in the archive, either or both of which may have made PPM happier. Thanks for your input; it'll be interesting to see what the M::B and A::T people say about this... -- 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 K. <ra...@th...> - 2004-01-12 23:15:11
|
On Mon, 12 Jan 2004, Glenn Linderman wrote:
> On approximately 1/12/2004 1:20 PM, came the following characters from
> the keyboard of Randy Kobes:
[ .. ]
> > I think the problem here is that the 'dist' build target
> > makes an archive suitable for CPAN, whereas the archive
> > that ppm expects (as specified by the codebase) is just
> > an archive of the blib/ directory. Try
> > perl build ppd
> > tar cvf GFfP-0.1.tar blib
> > gzip --best GFfP-0.1.tar
> > ppm install GFfP.ppd
>
> Hmm. I don't know enough about CPAN or PPM to verify or contradict this
> speculation.
>
> I started using Module::Build because it seemed like it was supposed to
> be an easier way to build packages that MakeMaker. If what you say
> above is, indeed, correct and turns out to be "the problem", then it
> would seems that either Module::Build needs an additional target to
> build distributions for PPM, or else I missed understanding which target
> I should use when I read the Module::Build documentation.
>
> If a different .tar.gz file is the problem, I'd think it
> should be bundled into the perl build ppd command, such
> that that command builds the two files necessary to use
> with PPM. I don't have a solution or recommendation for
> the naming conflict that results from having two different
> .tar.gz files for two different purposes for the same
> module for CPAN vs PPM. Maybe the substrings "-CPAN" and
> "-PPM" should be added into the .tar.gz file name
> somewhere.
You're right that the ppd target would need to be changed
in order to build the archive that ppm expects - something
like the following:
=========================================================
Index: lib/Module/Build/PPMMaker.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/PPMMaker.pm,v
retrieving revision 1.6
diff -u -r1.6 PPMMaker.pm
--- lib/Module/Build/PPMMaker.pm 9 Jan 2004 17:06:21 -0000 1.6
+++ lib/Module/Build/PPMMaker.pm 12 Jan 2004 22:56:57 -0000
@@ -1,6 +1,8 @@
package Module::Build::PPMMaker;
use strict;
+use File::Find;
+use Archive::Tar;
# This code is mostly borrowed from ExtUtils::MM_Unix 6.10_03, with a
# few tweaks based on the PPD spec at
@@ -24,9 +26,10 @@
my $distfile = $build->dist_dir . ".tar.gz";
print "Using default codebase '$distfile'\n";
@codebase = ($distfile);
- }
+ $self->make_archive($distfile);
+ }
- my %dist;
+ my %dist;
foreach my $info (qw(name author abstract version)) {
my $method = "dist_$info";
$dist{$info} = $build->$method() or die "Can't determine distribution's $info\n";
@@ -121,6 +124,16 @@
# generates something like "0,18,0,0"
return join ',', (split(/\./, $version), (0)x4)[0..3];
+}
+
+sub make_archive {
+ my ($self, $distfile) = @_;
+ my @f;
+ my $arc = Archive::Tar->new();
+ finddepth(sub { push @f, $File::Find::name;
+ print $File::Find::name,"\n"}, 'blib');
+ $arc->add_files(@f);
+ $arc->write($distfile, 1);
}
sub _varchname { # Copied from PPM.pm
==================================================================
would work, minimally. Then
perl build ppd
ppm install Module-Name.ppd
would be enough to install the package via ppm.
> The command sequence you offered above does, in fact,
> work. But I don't know enough to know if it is because I
> am using a different version of TAR (not Archive::Tar), or
> because there are fewer files in the archive,
> either or both of which may have made PPM happier.
The question of using A::T I think is separate ... Making
an archive for installing a ppm package on the same machine
should work with any version of A::T - where issues with
A::T come in is in making an archive for use on a different
platform (specifically, Win32).
The two archives serve different purposes - the one
currently made with the 'dist' target (composed of the files
in MANIFEST) are for making a CPAN compatible distribution,
whereas the one consisting just of the blib/ directory is
for a binary ppm distribution. In a loose sense the two are
orthogonal - the CPAN archive contains all files except
those in blib/, and the ppm archive contains only the blib/
files.
--
best regards,
randy
|
|
From: Glenn L. <pe...@ne...> - 2004-01-13 00:09:02
|
On approximately 1/12/2004 3:12 PM, came the following characters from
the keyboard of Randy Kobes:
> On Mon, 12 Jan 2004, Glenn Linderman wrote:
>
>
>>On approximately 1/12/2004 1:20 PM, came the following characters from
>>the keyboard of Randy Kobes:
>
> [ .. ]
>
>>>I think the problem here is that the 'dist' build target
>>>makes an archive suitable for CPAN, whereas the archive
>>>that ppm expects (as specified by the codebase) is just
>>>an archive of the blib/ directory. Try
>>> perl build ppd
>>> tar cvf GFfP-0.1.tar blib
>>> gzip --best GFfP-0.1.tar
>>> ppm install GFfP.ppd
>>
>>Hmm. I don't know enough about CPAN or PPM to verify or contradict this
>> speculation.
>>
>>I started using Module::Build because it seemed like it was supposed to
>>be an easier way to build packages that MakeMaker. If what you say
>>above is, indeed, correct and turns out to be "the problem", then it
>>would seems that either Module::Build needs an additional target to
>>build distributions for PPM, or else I missed understanding which target
>> I should use when I read the Module::Build documentation.
>>
>>If a different .tar.gz file is the problem, I'd think it
>>should be bundled into the perl build ppd command, such
>>that that command builds the two files necessary to use
>>with PPM. I don't have a solution or recommendation for
>>the naming conflict that results from having two different
>>.tar.gz files for two different purposes for the same
>>module for CPAN vs PPM. Maybe the substrings "-CPAN" and
>>"-PPM" should be added into the .tar.gz file name
>>somewhere.
>
>
> You're right that the ppd target would need to be changed
> in order to build the archive that ppm expects - something
> like the following:
> =========================================================
> Index: lib/Module/Build/PPMMaker.pm
> ===================================================================
> RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/PPMMaker.pm,v
> retrieving revision 1.6
> diff -u -r1.6 PPMMaker.pm
> --- lib/Module/Build/PPMMaker.pm 9 Jan 2004 17:06:21 -0000 1.6
> +++ lib/Module/Build/PPMMaker.pm 12 Jan 2004 22:56:57 -0000
> @@ -1,6 +1,8 @@
> package Module::Build::PPMMaker;
>
> use strict;
> +use File::Find;
> +use Archive::Tar;
>
> # This code is mostly borrowed from ExtUtils::MM_Unix 6.10_03, with a
> # few tweaks based on the PPD spec at
> @@ -24,9 +26,10 @@
> my $distfile = $build->dist_dir . ".tar.gz";
> print "Using default codebase '$distfile'\n";
> @codebase = ($distfile);
> - }
> + $self->make_archive($distfile);
> + }
>
> - my %dist;
> + my %dist;
> foreach my $info (qw(name author abstract version)) {
> my $method = "dist_$info";
> $dist{$info} = $build->$method() or die "Can't determine distribution's $info\n";
> @@ -121,6 +124,16 @@
>
> # generates something like "0,18,0,0"
> return join ',', (split(/\./, $version), (0)x4)[0..3];
> +}
> +
> +sub make_archive {
> + my ($self, $distfile) = @_;
> + my @f;
> + my $arc = Archive::Tar->new();
> + finddepth(sub { push @f, $File::Find::name;
> + print $File::Find::name,"\n"}, 'blib');
> + $arc->add_files(@f);
> + $arc->write($distfile, 1);
> }
>
> sub _varchname { # Copied from PPM.pm
> ==================================================================
> would work, minimally. Then
> perl build ppd
> ppm install Module-Name.ppd
> would be enough to install the package via ppm.
>
>
>>The command sequence you offered above does, in fact,
>>work. But I don't know enough to know if it is because I
>>am using a different version of TAR (not Archive::Tar), or
>>because there are fewer files in the archive,
>> either or both of which may have made PPM happier.
>
>
> The question of using A::T I think is separate ... Making
> an archive for installing a ppm package on the same machine
> should work with any version of A::T - where issues with
> A::T come in is in making an archive for use on a different
> platform (specifically, Win32).
Well my first problem is that I can't use M::B to build a package that
will install on the same machine it is built on! I had a number of
symptoms, most of which are now resolved, and at least one of which came
from the use of A::T, but yet unresolved is major issue of being able to
install via PPM using what M::B builds.
> The two archives serve different purposes - the one
> currently made with the 'dist' target (composed of the files
> in MANIFEST) are for making a CPAN compatible distribution,
> whereas the one consisting just of the blib/ directory is
> for a binary ppm distribution. In a loose sense the two are
> orthogonal - the CPAN archive contains all files except
> those in blib/, and the ppm archive contains only the blib/
> files.
Seems like the archive made with M::B dist target does contain blib
contents. Now maybe that is because I stuck lots of bad things in my
MANIFEST (which I just whacked at until it worked, except something
still doesn't)...
MANIFEST This list of files
META.yml no clue, but Module::Build wants it
build.pl Module::Build facility
blib/lib/GFfP.pm The main module (but no brains)
blib/arch/auto/GFfP/GFfP.bs no clue
blib/arch/auto/GFfP/GFfP.dll The brains for the module
blib/arch/auto/GFfP/GFfP.exp related to the .dll somehow
blib/arch/auto/GFfP/GFfP.lib related to the .dll somehow
With this MANIFEST, I get errors when I first run M::B (or after a
realclean), saying that the stuff that isn't built yet, isn't there, so
therefore the package isn't complete. That bothers me somewhat, and
maybe the reason is because of what you are saying about the difference
between the archives. But including these files in MANIFEST seemed to
be the only way to get them in the archive! And the M::B people have
seen my MANIFEST in my test case before.
I also wasn't particularly thrilled with moving my "source" GFfP.pm into
blib/lib, as I think it would be too easy to want to delete blib
directory... I'd have expected a structure where the .pm file was in the
root directory, and then got copied into blib/lib during the build process.
Pardon all my ignorances, but this is my first "written from scratch"
module, and although I've read a bunch of docs, most of this doesn't
seem to be particularly well documented unless it is already understood.
Or else I've missed where MANIFEST contents are documented. I have to
confess to not reading any MakeMaker documentation, since I chose to try
out M::B instead. But a MakeMaker module I've worked on some clearly
keeps its source .pm files in the root of the file structure... and has
no blib references in its MANIFEST. So that's why I was surprised,
probably.
--
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 K. <ra...@th...> - 2004-01-13 03:41:56
|
On Mon, 12 Jan 2004, Glenn Linderman wrote: [ ... ] > Seems like the archive made with M::B dist target does > contain blib contents. Now maybe that is because I stuck > lots of bad things in my MANIFEST (which I just whacked at > until it worked, except something still doesn't)... > > MANIFEST This list of files > META.yml no clue, but Module::Build wants it > build.pl Module::Build facility > blib/lib/GFfP.pm The main module (but no brains) > blib/arch/auto/GFfP/GFfP.bs no clue > blib/arch/auto/GFfP/GFfP.dll The brains for the module > blib/arch/auto/GFfP/GFfP.exp related to the .dll somehow > blib/arch/auto/GFfP/GFfP.lib related to the .dll somehow > > With this MANIFEST, I get errors when I first run M::B (or > after a realclean), saying that the stuff that isn't built > yet, isn't there, so therefore the package isn't complete. > That bothers me somewhat, and maybe the reason is because > of what you are saying about the difference between the > archives. But including these files in MANIFEST seemed to > be the only way to get them in the archive! And the M::B > people have seen my MANIFEST in my test case before. > > I also wasn't particularly thrilled with moving my > "source" GFfP.pm into blib/lib, as I think it would be too > easy to want to delete blib directory... I'd have expected > a structure where the .pm file was in the root directory, > and then got copied into blib/lib during the build > process. That's probably a good idea to not put stuff in blib/ from the outset. As well as the blib/ directory potentially getting deleted, the build process might overwrite some files in blib/, or some unwanted files there may get installed (eg, a Win32 dll gets put into a non-Win32 system). Finally, I think the PAUSE indexer ignores files under blib/, so tools like CPAN/CPANPLUS, which uses the PAUSE indices, might not see your modules. > Pardon all my ignorances, but this is my first "written > from scratch" module, and although I've read a bunch of > docs, most of this doesn't seem to be particularly well > documented unless it is already understood. > Or else I've missed where MANIFEST contents are > documented. I have to confess to not reading any > MakeMaker documentation, since I chose to try out M::B > instead. But a MakeMaker module I've worked on some > clearly keeps its source .pm files in the root of the file > structure... and has no blib references in its MANIFEST. > So that's why I was surprised, probably. If your goal for the package is to provide both the sources (for systems with a compiler) and a Win32 ppm package, what you could do is make up an ordinary package (without a blib/ directory), so users with a compiler will build it normally. Then, add into the distribution the M::B generated ppd file, plus an archive that you make up consisting of just the contents of the blib/ directory that results after you build it (assuming on Win32). As you mentioned earlier, you may want to rename this archive to something that won't conflict with that made by the dist target - you can call it anything you want, as long as the codebase of the ppd file is adjusted accordingly. Then, all a Win32 user would have to do is to ppm install Your-Package.ppd to install it - they wouldn't have to build anything. If you wanted to adjust things so a Win32 user would go through perl Build.PL perl Build perl Build test perl Build install to do all this, you could subclass Module::Build for Win32 to, eg, run 'ppm install Your-Package.ppd' for the install target, and unpack the archive (into a blib/ directory) which will be used in running the tests. -- best regards, randy |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-13 03:51:33
|
Sorry, I've been busy today and it will likely be tomorrow or so before I can frame a decent response, but here are my preliminary thoughts. * The 'make longlink? 0 0' output lines are debugging output, so that can be ignored that for the moment. * Module::Build needs to be patched to set $Archive::Tar::DO_NOT_USE_PREFIX=1 if $Archive::Tar::VERSION >= 1.09. * My biggest mistake is not asking Randy Kobes in on this discussion along time ago. It never occured to me that the contents of the archive where wrong for a ppm distribution. (In my defense, I did say I was not a ppm user. :) Thanks Randy. * For backwards compatibility (not really sure it's neccessary at this point, but...) I'd suggest leaving the 'ppd' action as is, and create a new 'ppm_dist' action that runs the 'ppd' action and creates an archive of the blib directory, running the 'build' action if neccessary. Ken? * We need a tutorial that goes step by step through building a M::B dist. Didn't Dave write one? Is it available online? * Glen, you should not have to modify the MANIFEST file; the 'manifest' action will automatically generate it for you. You may on occasion have to create a MANIFEST.SKIP file to exclude files from the scan that happens when you 'perl Build manifest'. See the docs for ExtUtils::MakeMaker & ExtUtils::Manifest for more info. I have not had a chance to test A::T yet, but assuming it works, it looks like we have all the pieces and we just need to assemble them. Randy's patch would make a great basis for writting the new action. If no one else does (and hopefully someone will), I'll try to come up with something in the next day or two. Thanks to Jos for working to update A::T for us who are sometimes stuck on a lesser OS. Thanks again to Randy for finding a solution to the failing ppm installations and for the code showing how it should be done. Thanks to Glenn for finding these problems and for being patient while working them out. Regards, Randy. |
|
From: Jos I. B. <ka...@dw...> - 2004-01-13 08:22:44
Attachments:
Archive-Tar-1.08_02.tar.gz
|
On 12-jan-04, at 19:38, Glenn Linderman wrote: > While at the end, ppm claims to have install GFfP, none of the files > have actually been installed. judging from my mistakingly left debug output, the new option isn't turned on either, so in effect nothing changed... what needs to happen to make this work with M::B is: A) patch M::B to use the $Archive::Tar::DO_NOT_USE_PREFIX flag B) create an archive with M::B from a dir structure with at least one file of > 100 chars, like in: http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- Pluggable-Module-SimpleBlog-0.02.tar.gz C) attempt to extract this file with your tar extractor of choice > Along the way, PowerArchiver 2001 isn't able to see the pathnames. well, nothing changed yet :) > I see a bunch of new messages about "make longlink? 0 0" during the > build of the TAR file; maybe I need a newer version of Module::Build > to turn on the new option in Archive::Tar? Maybe the message is just > a debugging message to see if M::B actually turned on the option? it's my mistakingly left debug output... i've attached 1.08_02 that doesn't have this noise... p.s. please /please/ stop sending me all emails twice, thanks -- Jos Boumans "Whenever you find you are on the side of the majority, it is time to pause and reflect." - Mark Twain CPANPLUS http://cpanplus.sf.net |
|
From: Glenn L. <pe...@ne...> - 2004-01-13 08:59:17
|
On approximately 1/13/2004 12:22 AM, came the following characters from the keyboard of Jos I. Boumans: > > On 12-jan-04, at 19:38, Glenn Linderman wrote: > > what needs to happen to make this work with M::B is: > A) patch M::B to use the $Archive::Tar::DO_NOT_USE_PREFIX flag > B) create an archive with M::B from a dir structure with at least one > file of > 100 > chars, like in: > http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- > Pluggable-Module-SimpleBlog-0.02.tar.gz > C) attempt to extract this file with your tar extractor of choice Why should I make my module have a file of > 100 chars? Such a name is much too long, in my opinion, for this module of interest. I believe that you have my test case, and can see that there are no files with names > 100 chars. If the problems with PowerArchiver (and other utilities) seeing pathnames are related to pathnames that are longer than 100 characters, why are those other utilities having problems displaying the directory names from the output of A::T when the pathnames are less than 100 characters? I think we are still missing something here. >> Along the way, PowerArchiver 2001 isn't able to see the pathnames. > > well, nothing changed yet :) OK, I understand that. I didn't necessarily expect that anything would change, without corresponding fixes to M::B, but wanted to do due diligence and find out. Especially, because I still don't know why people are fixing and discussing > 100 character pathnames, when my test case that fails doesn't have any! Not that it isn't an interesting discussion, and not that the fixes won't be welcome, of course, as from all accounts that I've heard, some improvements can be made. > p.s. please /please/ stop sending me all emails twice, thanks Could you please clarify if you are subscribed to receive all the module-build-general messages? I'm under the understanding that you are not, and using that understanding, you only seem to appear in my list of addressees once, for this message, and every other message that I've sent. -- 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: Glenn L. <pe...@ne...> - 2004-01-20 03:39:51
|
On approximately 1/13/2004 12:59 AM, came the following characters from the keyboard of Glenn Linderman: > Especially, because I still don't know why people are fixing and > discussing > 100 character pathnames, when my test case that fails > doesn't have any! Any progress on this point yet? I've been away for a few days, but didn't see any new traffic on the topic. >> p.s. please /please/ stop sending me all emails twice, thanks Someone observing these discussions figured out the problem here, and informed me of it. In the interest of helping solve the root cause, I describe the problem and solution here. When you are addressed as "ka...@cp..." you then reply from "ka...@dw...", and don't elide your own (apparently alias) from the Cc: list. That winds up putting both "ka...@cp..." and "ka...@dw..." into the To: or Cc: list of people that then reply-all to your message. You need teach your mail client to reply from the same address via which the message arrived... or teach it to elide your own aliases from the To: and Cc: lists. Putting the burden of your own deficient mail client configuration on everyone else to resolve isn't likely to reduce your duplicate incoming email significantly. -- 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: Jos I. B. <ka...@dw...> - 2004-01-20 08:37:45
|
On Jan 13, 2004, at 9:59 AM, Glenn Linderman wrote: > On approximately 1/13/2004 12:22 AM, came the following characters from > the keyboard of Jos I. Boumans: >> On 12-jan-04, at 19:38, Glenn Linderman wrote: >> what needs to happen to make this work with M::B is: >> A) patch M::B to use the $Archive::Tar::DO_NOT_USE_PREFIX flag >> B) create an archive with M::B from a dir structure with at least one >> file of > 100 >> chars, like in: >> http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- >> Pluggable-Module-SimpleBlog-0.02.tar.gz >> C) attempt to extract this file with your tar extractor of choice > > Why should I make my module have a file of > 100 chars? Such a name > is much too long, in my opinion, for this module of interest. *sigh* illustrated above is the way to guarantee that M::B will work properly with every archive A::T will create. The problem that came to light by your test case was an incompatibillity issue with older tar clients. This particular problem has been fixed as described in a previous mail, and i'm waiting for results from the testers (ie you and randy). > I believe that you have my test case, and can see that there are no > files with names > 100 chars. your test case is no longer relevant here, as stated above, since it merely pointed at the incompatibillity, rather than using it in the 'worst case possible'. > If the problems with PowerArchiver (and other utilities) seeing > pathnames are related to pathnames that are longer than 100 > characters, why are those other utilities having problems displaying > the directory names from the output of A::T when the pathnames are > less than 100 characters? > > I think we are still missing something here. no, still same problem -- A::T uses the prefix header (even sometimes for paths < 100 characters) and older clients just don't recognise it... On Jan 20, 2004, at 4:40 AM, Glenn Linderman wrote: > On approximately 1/13/2004 12:59 AM, came the following characters from > the keyboard of Glenn Linderman: > >> Especially, because I still don't know why people are fixing and >> discussing > 100 character pathnames, when my test case that fails >> doesn't have any! > Any progress on this point yet? I've been away for a few days, but > didn't see any new traffic on the topic. point A) from the above list needs to first be adressed and tested -- 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: Glenn L. <pe...@ne...> - 2004-01-20 09:35:11
|
On approximately 1/20/2004 12:34 AM, came the following characters from the keyboard of Jos I. Boumans: > > On Jan 13, 2004, at 9:59 AM, Glenn Linderman wrote: > >> On approximately 1/13/2004 12:22 AM, came the following characters from >> the keyboard of Jos I. Boumans: >> >>> On 12-jan-04, at 19:38, Glenn Linderman wrote: >>> what needs to happen to make this work with M::B is: >>> A) patch M::B to use the $Archive::Tar::DO_NOT_USE_PREFIX flag >>> B) create an archive with M::B from a dir structure with at least one >>> file of > 100 >>> chars, like in: >>> http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- >>> Pluggable-Module-SimpleBlog-0.02.tar.gz >>> C) attempt to extract this file with your tar extractor of choice >> >> >> Why should I make my module have a file of > 100 chars? Such a name >> is much too long, in my opinion, for this module of interest. > > *sigh* > > illustrated above is the way to guarantee that M::B will work properly > with every archive A::T will create. The problem that came to light by > your test case was an incompatibillity issue with older tar clients. > This particular problem has been fixed as described in a previous mail, > and i'm waiting for results from the testers (ie you and randy). > >> I believe that you have my test case, and can see that there are no >> files with names > 100 chars. > > your test case is no longer relevant here, as stated above, since it > merely pointed at the incompatibillity, rather than using it in the > 'worst case possible'. So let me see if I understand: you have fixed an incompatibility with older tar clients, and are waiting for Randy and I to test it. Except that my test case is no longer relevant, so why wait for me to test it? >> If the problems with PowerArchiver (and other utilities) seeing >> pathnames are related to pathnames that are longer than 100 >> characters, why are those other utilities having problems displaying >> the directory names from the output of A::T when the pathnames are >> less than 100 characters? >> >> I think we are still missing something here. > > no, still same problem -- A::T uses the prefix header (even sometimes > for paths < 100 characters) and older clients just don't recognise it... And here, as far as I can tell, you state that there will still be an incompatibility with older tar clients, so as far as I can tell, there isn't a lot of point in testing something that has no chance of helping the incompatibility. So you may understand perfectly well what is going on, but from what I can tell, even if I should come up with a test case to test your fixes, I still won't have a solution to the incompatibility I am actually experiencing with older tar clients. The way I understand this issue, which may be totally wrong, is as follows: 1) older tars didn't have prefix headers, and were limited to pathnames <= 100 bytes in total length. 2) Some tar or another implemented a solution that allowed > 100 byte pathnames, but had its own limit of <= 256 bytes. 3) GNU tar implemented one or more extensions that allowed pathnames > 100 bytes. 4) Some tar standards committee implemented some extensions that allowed pathnames greater than 100 bytes. The file format implemented by this solution is incompatible with all older tar clients. 5) implementations 2, 3, and 4 are incompatible, when path names are greater than 100 bytes. So then, it now appears that although my test case is demonstrating a problem with using the new file format for archives containing only pathnames <= 100 bytes, the problem you are fixing has to do with the incompatibilities among the various solutions for archives containing pathnames > 100 bytes? On my very first job back in 1979, I was introduced to the concept of "backward compatibility"... the goal being to keep the data transportable between older and newer versions of software, and the programming APIs from older versions to still function the same in newer versions. The purpose behind that goal was to maximize the ability of the customer to get work done. It appears that since the new tar file format in point (4) above causes incompatibility problems with older software programs, that it should only be used when it is needed, and that the older file format (from point (1) above) should be used when the new format is not needed. This would maximize the ability of users to interoperate with their data using various old and new software programs. Are there any other solutions that achieve this maximal data compatibility? Clearly if a user of a new program, needing the new feature of > 100 byte pathnames, creates an archive, it will not be compatible with old programs that can only deal with <= 100 byte pathnames. At the time of creation of such an archive, the user should be warned that it uses features from whatever (point 2, 3, and/or 4) above that permit the pathnames to be >= 100 bytes, and that the resultant archive may not be compatible with tar programs that do not have that feature. > On Jan 20, 2004, at 4:40 AM, Glenn Linderman wrote: > >> On approximately 1/13/2004 12:59 AM, came the following characters from >> the keyboard of Glenn Linderman: >> >>> Especially, because I still don't know why people are fixing and >>> discussing > 100 character pathnames, when my test case that fails >>> doesn't have any! >> >> Any progress on this point yet? I've been away for a few days, but >> didn't see any new traffic on the topic. > > point A) from the above list needs to first be adressed and tested So I think that is what Randy did in the message below. I think basically that he verified your statement that my test case (which is also his test case for my problem) is not relevant to what you fixed. So we, as testers (at least I, as tester), am waiting for a fix for the problem I actually have, rather than a fix for a problem that I don't have (but which sounds like it needs to be fixed, nonetheless). OK, so how far off am I in my understanding of what is going on? On 1/13/2004 3:35 PM, Randy W. Sims wrote: > On 1/12/2004 6:15 AM, Jos I. Boumans wrote: > >>> YES! Looks good. I will test more extensively when a snapshot is >>> available. Thanks. >> >> You can find a snapshot attached. To use the new feature, follow this bit of documentation: > > I've tried both versions with no success after modifying Module::Build with the patch below. I get the same result whether DO_NOT_USE_PREFIX is true or false. WinZip and PowerArchiver can not read the path info, while WinRAR and at least one port of GNU tar can read it. > > Randy. > > $ diff -u Base.pm.orig Base.pm > --- Base.pm.orig 2004-01-10 23:19:59.000000000 -0500 > +++ Base.pm 2004-01-13 18:01:36.000000000 -0500 > @@ -1741,6 +1741,9 @@ > $self->do_system($self->{args}{gzip}, "$dir.tar") if $self->{args}{gzip}; > } else { > require Archive::Tar; > + # Archive::Tar versions >= 1.09 use the following to enable a compatibility > + # hack so that the resulting archive is compatible with older clients. > + $Archive::Tar::DO_NOT_USE_PREFIX = 1; > my $files = $self->rscan_dir($dir); > Archive::Tar->create_archive("$dir.tar.gz", 1, @$files); > } -- 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-13 23:35:27
|
On 1/12/2004 6:15 AM, Jos I. Boumans wrote:
>> YES! Looks good. I will test more extensively when a snapshot is
>> available. Thanks.
>
>
> You can find a snapshot attached. To use the new feature, follow this
> bit of documentation:
>
I've tried both versions with no success after modifying Module::Build
with the patch below. I get the same result whether DO_NOT_USE_PREFIX is
true or false. WinZip and PowerArchiver can not read the path info,
while WinRAR and at least one port of GNU tar can read it.
Randy.
$ diff -u Base.pm.orig Base.pm
--- Base.pm.orig 2004-01-10 23:19:59.000000000 -0500
+++ Base.pm 2004-01-13 18:01:36.000000000 -0500
@@ -1741,6 +1741,9 @@
$self->do_system($self->{args}{gzip}, "$dir.tar") if
$self->{args}{gzip};
} else {
require Archive::Tar;
+ # Archive::Tar versions >= 1.09 use the following to enable a
compatibility
+ # hack so that the resulting archive is compatible with older clients.
+ $Archive::Tar::DO_NOT_USE_PREFIX = 1;
my $files = $self->rscan_dir($dir);
Archive::Tar->create_archive("$dir.tar.gz", 1, @$files);
}
|
|
From: Glenn L. <pe...@ne...> - 2004-01-07 22:47:33
|
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) 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 >> 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. > 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. > > -- > > Jos Boumans > > "If superman is so smart, why does he wear underpants over his > trousers?" > > CPANPLUS http://cpanplus.sf.net > > > > ------------------------------------------------------- > 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/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing. |
Thanks for helping keep SourceForge clean.
X