1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
[[meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled
[[GNU_Free_Documentation_License|/fdl]]."]]"""]]
[[meta title="Have Debian's apt use ftpfs"]]
\#hurd [[IRC]] channel, 2009-03-13.
<tschwinge> By the way: I had another GSoC idea:
<tschwinge> (a) make ftpfs / httpfs unsable enough for...
<tschwinge> (b) have Debian's apt / whetever not use a direct ftp / http
connection, but instead use /ftp/ftp.debian.org/whatever etc.
<tschwinge> (c) Make unionfs unsable enough, so that it can be used
together with nfs (or whatever) to sarve as a cache for /ftp/.
<antrik> uhm... you mean all of this as a single GSoC project?
<antrik> indeed I have the intention of turning ftpfs/httpfs into something
that can be used by other tools instead of a library
<antrik> but that requires them to grow completely new interfaces, making
them suitable for interactive use
<antrik> you are right though that this would be a nice GSoC project... no
idea why I never thought of it in this context
<tschwinge> I think I proposed this idea already some months ago on some
mailing list.
<tschwinge> I don't think it's too much work.
<tschwinge> Or why do you think?
<antrik> it is considerable work
<antrik> it requires implementing a non-trivial, directory based FS
interface
<tschwinge> (c), OK, but why (a) and (b)?
<antrik> also, I'd probably reimplement them on top of libcurl... no need
to maintain our own wheels :-)
<tschwinge> That for sure, yes. But for starterst, we can just take ftpfs
as it is.
<antrik> I think I explained the issues in some past discussion, though I
don't remember where it was
<tschwinge> And just teach apt to open /ftp/... instead of calling whatever
function to retrieve a ftp file.
<antrik> you want progress tracking for one
<antrik> you want the client to see redirects
<antrik> (OK, that might not be necessary for apt-get... it would be
necessary for other use cases like a web browser, though)
<antrik> you want proper error handlin
<tschwinge> http://thread.gmane.org/gmane.os.hurd.bugs/16575/focus=16795
<antrik> none of this can be expressed by opening a single virtual file
<antrik> it would require adding a completely new interface, either using
custom RPCs, or a directory with several virtual files for various
aspects of the interaction
<antrik> (I prefer the latter variant, though I guess some people would
argue in favour of the former :-) )
<antrik> anyways, I'll add it to the list
<tschwinge> OK, I see. Nevertheless, don't you think that a more simple
implementation of my idea (also leaving out (c) for now) wouldn't be a
suitable GSoC project?
<antrik> apt-get is probably quite a good example use case for this, so you
are probably right that it would be useful to develop this together
<antrik> (I'll leave out (c) though -- I would consider it a distinct
project. we can place a followup task once (a)+(b) is done :-) )
<tschwinge> Yes, sure.
|
