On 9/7/05, Giacomo A. Catenazzi <[EMAIL PROTECTED]> wrote: > Eddy Petrişor wrote: > > Hello Giacomo, > > > > I have observed that you have applied a part of my patch to apt-zip > > 0.13.3. Thanks for that. > > It seems that you have lost my previous mail ;-)
Probably... sorry > > The problem is that the patch was applied brokenly on apt-zip's code > > (I guess you took parts of it). > > > > The formatting is messed up in the wget method and the generated > > scripts; the patch I proposed used a trick for formatting and infile > > code: all the leading tabs are eliminated in the resulting output, but > > no the same for the spaces. (Probably) your editor replaced the tabs > > with spaces in some files and in some files didn't. > > yes. I applied by hand because my tree had already some previous changes. so I guess you accept my correction, as the generated scripts are broken in many ways > > Also the replacement of the less portable command "which" (not present > > on cygwin) with "type" was recorded in the changelog, but was not > > added to the code. > > I forgot it, But I uploaded a new version of apt-zip before I received > this mail, so now I deleted the whole check. > I think there are enough the check in IP/TCP and in wget (or alternate) > programs. Anyway dpkg will further check the package. I am sorry, but I don't see the connection to the initial point. In the generated scripts, "which gzip" is used to test whether gzip is present; which is less portable than type, so I changed that into "type gzip". (which is not present in cygwin, at least in my copy, while type is a built-in command and has a longer history, thus is more portable) > > I have made a new patch which fixes all the problems and adds suport > > for relative paths (please add this as I usually invoke apt-zip with a > > command like "apt-zip -s -m . -p codeville", and I am sure many could > > use it in the same way on a flash stick, as there is no need to make > > files in the root of the removable media). > > Ok. now I understand. You mean ".". Relative path support was already > included (as "zip", "../dir"). "." is a special case, because it > mount the filesystem, but I remain in the old ".". > I propose an alternate (simple?) way: cd . I really would prefer my approach as is more flexible: apt-zip-list -s -m relative_path_should/be/allowed Another important point is that if one uses relative paths, the apt-zip-* scripts would fail (in their curent form) as they expect to find the tar archive in a directory specified as an absolute path. I also fail to see the benefit of doing cd . , probably I am missing something. But, anyway is your package, you can decide if a feature is impotant/useful enough to be included. > > PS: The changelog is updated and your name is registered for the > > packahe maintainer ;-) Sorry for impersonating you :o) > > I don't agree on your changes in copyright files. It is not as > intended in policy. > Yann is included because we need a name. Really the copyright should > go in the 'normal' files and copyright should include the (old) maintainers, > main developers (but no need to keep updated). Weird, will keep in mind... I always thought this way of recoding copyright (distributed in files) is prone to problems later if somebody forgets to add that note... anyway -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein
