[Apt-zip-devel] Re: apt-zip

Eddy Petrișor eddy.petrisor at gmail.com
Thu Feb 15 22:13:49 CET 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Giacomo Catenazzi wrote:
> Some comments:

(damn, this mail is my drafts folder since last week)

Hello,

I also looked over the patch and what it produces. I took the liberty of
removing the quoting for some of the parameters (but I haven't tested
yet - I did the checking offline on a train)... hmm, thinking of it now
I might have done a mistake, but the code should work "by chance" since
the last parameter is always the possibly missing one (the md5 sum).

I also made some change in the code that reports the size of download to
report "unknown" instead of 0, when that happens.

It looks generally ok, but I also dislike the unpacking and repacking.

I think the tar option could be implied, but is probably better to have
it explicitly since is unknown to "us" what is the remote tar.

> * You should add also the list address, so the patches and
>   discussions are archived:
>   Apt-zip Development Team <apt-zip-devel at lists.alioth.debian.org>
> 
> * Why do you decompress Packages file in the fetch script?
>   I think it is better to raw copy the file. Then in the host
>   machine you could decompress. In this mannes it doesn't
>   requires bzip2 or gunzip on the remote machine, and it
>   requires less space in medium.
> 
> * I think you should export only the name "Packages" to
>   the list of files to download.
>   The fetch script then should test it it exits the
>   .bz2 or the .gz files.
>   (so you remove also the "sed" requirement).
>   BTW I think apt-get cannot use raw (non compressed) Package,
>   but we can use as failover. Ev. in install script we can
>   compress it (but now I don't remember the requirement
>   of repositories, I should recheck the dpkg doc)

By default it doesn't fetch them. I know since I ran into that problem
with a repo I made with debpool. apt* refused to use it until I added
[gb]zipped version of the packages although the Release file said the
simple one was the only available.

>   As secundary note: We should always download the Packages
>   files and not the eventual diff files (as in etch and sid).
>   I'm not sure if diff now are the default or if it requires
>   addisional parameter. To check.

Is default but can be overridden.

> * BTW: we could add an option to download Packages also
>   during normal apt-zip-list operation.
>   So for frequent usage, user don't need double trip.

That would be nice, but it creates some issues:
1) you always must run the "active" action (install, upgrade,
dist-upgrade) first, then the update command
2) you will always need tar as an option

Maybe a separate function and section could be used ?

> * -	    ${CHECK} \$2 \$4 \$?
>   +	    ${CHECK} "\$2" "\$4" "\$?"
> 
>   Such quotation are useless, they are removed bye
>   first shell run (in home host).
>   Better is:
>   +	    ${CHECK} \"\$2\" \"\$4\" \"\$?\"
>   which on first run convert in
>       check "$1" "$4" "$?"
>   on the fetch script (ready for the second run).
> 
>   But it is not very readable. Anyway it could improve
>   security.

AFAIUI, the quotes were there to avoid spaces and whatnot, and the
missing "read" fileds from the list, but it seems to me this is not real
problem.

Please contradict me if I am wrong.

>   General comment.
>   In a long term maybe we should avoid the double run of
>   method scripts: they are not very readable, and it is
>   difficult to understand what code is run on target and
>   what code on home machine.

I agree, document here is hard to follow without syntax highlighting
and, more than that, some parts of the script are read from the output
of some other script, which is not that obvious (not even for me, since
every time I want to work on apt-zip I start from the generated script
and it becomes clear).

>   (maybe with %VAR% notation and some sed script that
>   substitute/insert variables and blocks)
>   But you, Fran,cois, ignore this for now. It should be
>   a long term change, during a eventual new rewrite.

Maybe a rewrite in another language, maybe?

We would have to choose that wisely since we might need some regexps and
things like that. Nothing stops us from going away from shell script on
the unconnected machine.

Perl seems appealing, but its readabilty sucks. Note that I found the
fact that apt-zip was written in shell a nice thing and it allowed me to
hack on it without the sources, so this was a plus, not sure if it makes
a difference.

(I agree with Giacomo, this is not a concern for you François.)

Slightly modified patch attached.

- --
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF1M0NY8Chqv3NRNoRAsF+AKCWxQ+lrFKIiUYKAaGPXxltm6w2cQCeJweI
3NVLpTL8DyCiXetZGXd19s8=
=oCnP
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update_support.patch
Type: text/x-diff
Size: 6247 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/apt-zip-devel/attachments/20070215/51e6d579/update_support.bin


More information about the apt-zip-devel mailing list