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

François Févotte francois.fevotte at ensta.org
Mon Mar 12 14:34:02 CET 2007


Hello,

I'm sorry I didn't respond to this any sooner, but I spent a few weeks
on holidays, and have had some difficulties catching up with my mail
since I returned.

I will work on the changes you suggested, and I should be able to send
you a corrected version very soon. The main issues on which I intend
to focus are:
* fix the parameter quoting issues
* don't uncompress downloaded Packages.[gz|bz2] files

Thanks,
   François

On 2/15/07, Eddy Petrișor <eddy.petrisor at gmail.com> wrote:
> -----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-----
>
>


More information about the apt-zip-devel mailing list