Eddy Petrişor wrote:
On 9/7/05, Giacomo A. Catenazzi <[EMAIL PROTECTED]> wrote:
Eddy Petrişor wrote:
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
yes.
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)
type is more common that which (type is in POSIX), but type has
not fix output.
Anyway the test seems not important, so I removed the whole check ()
function.
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 should test. On my (non complete) test I can use a relative path.
I also fail to see the benefit of doing cd . , probably I am missing something.
The trick is after mount the partition to go in the partition.
So any 'cd' command (if it go in the right dir) is good.
I'm not sure about cwd/PWD in solaris.
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
Here the problem is that there is no copyright statement on the other file.
And it is needed. I think debian/copyright is not the right place
(i.e. if the package will be packad for other distributions)
ciao
cate
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
