[Apt-zip-devel] debian methods - looking back and forward

[Eddy Petrișor]

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

Eddy Petrişor wrote:
> On 25/07/06, Giacomo A. Catenazzi <cate at debian.org> wrote:
>> Eddy Petrisor wrote:
>> > Author: eddyp-guest
>> > Date: 2006-07-24 00:18:52 +0000 (Mon, 24 Jul 2006)
>> > New Revision: 73
>> >
>> > Added:
>> >    branches/nix-scripts/methods/write-fetch-d4x
>>
>> Hello Eddy.
>>
>> I don't agree with your definiton of the fetch scripts ;-)
> For a moment I thought you were serious. In any case, I wanted to make
> some changes in a branch so it does not interefere with regular
> development, if any; also I wanted to be sure that there are no
> regressions before asking for advice.
> 
>> I think that the script should be smarter, so in one script
>> you should include support of curl, lynx and d4x.
> I guess the fetch function could try to identify which tools are
> available at run time, but as I said, I wanted first to have no
> regressions.

thinking again, I guess the best way would be to just make small
improvemnts, release, then improve...

I'll merge these changes in trunk post-etch

>> And we should use new scripts for very different methods,
>> where the changes are not only one line (i.e. for
>> smarter script (maybe graphical tk), which requires more
>> tools, .bat windoze script, ... ).
> That is still possible via the old way of creating scripts and looking
> at lftp man page, I think that is the way we will have to do it in
> that case.
> 
>> Anyway user at apot-zip-list time should be able to
>> set prefered order of script, (to overide wrong
>> tools). It would be nice if the user could
>> change also on fetch time (variable at the top,
>> i.e. IGNORE_LYNX='not no'), but than maybe it will be
>> difficult for a very portable script.
> Maybe IGNORE_METH='lynx wget', so will use curl even if wget and lynx
> exist.

still, I think this is post-etch material

>> anyway, thanks for the improvements!
> np, I had the idea after reading some Gentoo documentation which
> showed how polymorphism can be implemented in bash. Basicaly, if you
> redefine a function it will have the new functionality from that point
> on. That could be used in the way I did with write-fetch-${METHOD}
> sourcing. BTW, I don't remember if I used "source" or ".", but it
> seems "." is more portable.

Already I think more and more of reimplementing the thing in some
more flexible and readable langauge...

Hah, I just remembered, with the experimental dpkg-cross and cross
tools there might be a chance to be able to build some app for
windows...

I wonder if would be possible to build another package which apt-zip
recommends that during its build, builds a cross built wget or some
fetch tool for windows...


Also, another idea would be to separate the methods, place them in
/usr/lib/apt-zip/methods, directly built (building done during
ap-zip build stage or some apt-zip-method-* package), and add a
configuration file which would have the same format for any of the
methods (with some added options for each).


The task for apt-zip would be then just to generate a configuration
which the methods would use.

Add makeself to the mix or some similar working tool (I am thinking
about windows portability here) and delegate the auto-configuration
to the connected machine and you have a better tool...


Shell doesn't scale up, and that's why I think is not that popular
and known as we'd like.

- --
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF+qcWY8Chqv3NRNoRAlXSAKCRtaLH3WtmXKkmCKNx5O1xEy902QCgyO2x
3lxmrRzXPACWSyDCEVEW/5I=
=p7nx
-----END PGP SIGNATURE-----