[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