[Apt-zip-devel] Exporting USEMD5SUMS

[Eddy Petrișor]

Giacomo Catenazzi wrote:
> Eddy Petrișor wrote:
>> On 25/09/2007, Wolfram Sang <wolfram at the-dreams.de> wrote:
> 
>>>  By the way, is there some cvs/svn repository or is the source-package
>>>  the most recent version?
>> Yes and no. We tried using svn, but I think Giacomo has started
>> privately using git (the latest 2.5 releases are not in svn) and we
>> didn't discuss about this.
>>
>> The outdated code in SVN is at svn://svn.debian.org/svn/apt-zip/trunk .
>>
>>
>> BTW Giacomo, we could use git instead of svn, if you like. (And I know
>> I haven't done anything lately - like a year or more).
> 
> sorry :-(
> No, I'm not using git for this package.
> I'll use svn, now that I learned it ;-)
> Anyway, I tend to work in batch mode, so my local version is the same
> as the uploaded version (aka, "patch, test and upload" on same days).

I just finished importing and tagging the missing versions into subversion,
so now the svn version should be the same as the 0.18 release and should contain all the history 
contained in the archive (0.16, 0.17 and 0.18).

> BTW somebody proposed me an other design: a web based application.
> I see it as:
> - USER: upload of package list (+ installed version)
> - SERVER: find new packages (ev. with dependencies)
> - SERVER: display a link to the new generated tar file

I am fairly sure I have seen this proposal before, but I can't find he BR.

> As further step we can add:
> - dependencies search,
> - split big tar to an user defined max size (i.e. floppy)
> - user could save the package list
>   - easier to get new security or stable-update
>   - notified via email
> - ...

Yes, this sounds good. Still, the bottleneck here seems to be the server itslef. This would 
definitely have to be account (or some other authentication) based in order to prevent DoS attacks.

Also, apt-zip would be only responsible of creating a "local machine status" snapshot (states of the 
packages+sources.list{,.d/*}).

Still, I think this should *not* replace the current apt-zip-list and apt-zip-inst scripts until we 
have something really functional.

> Because the server will be in a debian machine, I think
> coding it will be a lot simpler that actual apt-zip.
> The only problem I see: resources. The apt is slow and
> resource intensive (dependencies), and I've no idea
> on bandwidth.

It depends on which packages are downloaded. We could impose a soft limit of (say) 50MB for a 
apt-zip-server upgrade and request direct usage of apt-zip-list update + apt-zip-list upgrade ... 
for bigger downloads.

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