[gentoo-portage-dev] Transports

[gentoo-portage-dev] Transports

[Alec Warner]

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

I was looking at Transport code last night and I noticed it only
supported HTTP/HTTPS/FTP, which I thought was kind of limited.  Thoughts
on merging the Sync code in with Transports, having the transport lib
covering all...well..file transport code within portage?  The Rsync code
is strikingly similar, and I was thinking of adding scp as well so
people have a lot of options.

Thoughts, objections...donuts?

- -Antarus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQpwGgWzglR5RwbyYAQKaJQ/+PR4wzmTNh9a+WhT5QRpjatG9kwZefP31
oCeGdnLeTJ+hyxfruQUTtKOFkEWq9rKEYBu5nTQT79Y8cMoprBHOiPIyjARAKL2Q
RtDXy/J9rVBbFcmgbRdWpvq5JCCurq7euMcnP4mmqYc8VOrv3rm5Xb//s9KIXX1G
JLnPqr0aDTeEmi69EOsUTLuXkIMq275PrQygDy4D9JrSGj88xv8IOYHQcaoaSLKc
mMiI4QYD+htLVqzISFt37KEhnfSKit5sqA1ToqjWiw9nMboZOcoAKmYfot+F7JNu
vMqT7SIna5Q60FrlVymkMDkvvdpJqic2gAuIrPM7UDGqtkmxegFVHuz3b4lpjEf7
olTAW8ztDfwKWyoDU77hj01KcPdg5lOOc9L2nU1GBvocbmIU4UXTSFMRKOvZEfd2
0G4PRA/jw+LKM63Ikk+OXebbOQYWRGEJKpVtfM2soJ/uQYtEBxvfG8fMTStFe3Ez
JyMR0UhAaJkEsoSIorRi1SNdWGfB20mx61za2P58jtDQUVbfU++ZL2HYplI0sX+f
o8WR6r14gIva1W3Gx+BGCCg0wR7YQL5b2tUgHvxkyFlZqYsvNtfnM2Yk7k6uVK3f
Bb6LiwCAzv1RBjo4bXi4A5wkm69VsaDWhToaV6D6lpPftkoXbo/iRptgbU36HJoH
p86aVAsnJ30=
=ymRi
-----END PGP SIGNATURE-----
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Transports

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

On Tue, May 31, 2005 at 02:38:58AM -0400, Alec Warner wrote:
> I was looking at Transport code last night and I noticed it only
> supported HTTP/HTTPS/FTP, which I thought was kind of limited.  Thoughts
> on merging the Sync code in with Transports, having the transport lib
> covering all...well..file transport code within portage?  The Rsync code
> is strikingly similar, and I was thinking of adding scp as well so
> people have a lot of options.
> 
> Thoughts, objections...donuts?
I like cheese. ?

scp doesn't support resume, so it differs from existing transports if 
added.  For merging of sync and transports, transports is specifically 
single file network io requests, sync can mangle multiple files.  

Dunno, possible.
Honestly sync and transports could use a mild set of touch ups, 
although not sure about collapsing/combining the sync/transports bit.
Reasons for it, aside from having a few more protocols able to be 
handled?  Hadn't thought about the possibility of supporting cvs for 
SRC_URI- that would be nifty, although would need a way to specify a 
required atom for protocols (if this cpv has cvs://blar in it, it 
requires dev-util/cvs, or preferably a virtual should dev-util/cvs 
ever move...
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Transports

[Alec Warner]

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

Brian Harring wrote:
> On Tue, May 31, 2005 at 02:38:58AM -0400, Alec Warner wrote:
> 
>>I was looking at Transport code last night and I noticed it only
>>supported HTTP/HTTPS/FTP, which I thought was kind of limited.  Thoughts
>>on merging the Sync code in with Transports, having the transport lib
>>covering all...well..file transport code within portage?  The Rsync code
>>is strikingly similar, and I was thinking of adding scp as well so
>>people have a lot of options.
>>
>>Thoughts, objections...donuts?
> 
> I like cheese. ?
> 
> scp doesn't support resume, so it differs from existing transports if 
> added.  For merging of sync and transports, transports is specifically 
 Bleh, not all FTP is resumable either, depends on server settings IIRC
( although almost all recent servers support it ).
> single file network io requests, sync can mangle multiple files.  
> 

Mostly was looking at a unified transport lib, with connection
abstractions, which is basically what we have now, but lacks SCP/RSYNC
support, and I think people would want that functionality, Remote repos
with rsync for proto fex.  That way the remote repo code only depends on
Transports and all the proto mess is abstracted away.  Maybe just keep
em seperate and copy the rsync code?  I kind of like the single vs multi
approach now that I think about it more :P

> Dunno, possible.
> Honestly sync and transports could use a mild set of touch ups, 
> although not sure about collapsing/combining the sync/transports bit.
> Reasons for it, aside from having a few more protocols able to be 
> handled?  Hadn't thought about the possibility of supporting cvs for 
> SRC_URI- that would be nifty, although would need a way to specify a 
> required atom for protocols (if this cpv has cvs://blar in it, it 
> requires dev-util/cvs, or preferably a virtual should dev-util/cvs 
> ever move...
> ~brian
Anything wrong with adding local portage USE flags? :)
sys-apps/portage:cvs-transport - Allow CVS to be used for SRC_URI/Binary
fetching.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQpyA2GzglR5RwbyYAQKd7w/+MU16nG4XIj/8h3aCx4dwqfBYwog2HBC2
0qAKkJnkiFKz53wWJwzL20XhiUiNlvsSVkH2qcj7w+GoOBEXnQAw4a0oTA+OR0qz
A6jrwJ5JKXPG+XISStMFMe/oCeg6j0M6+BRMCgYj0Rx9MfjFfLJOeAtDaXgUoG48
MaQhnko6ufmx7Y5OmbznJysEwV76ki47k3m2k7NhLrPa/z/4kfWfhatz4Z7l1pO+
2K/MUWVx1vbPZxd+ixxCLeX9MS0sf5Oh5y8R+sNCuCCJYhUp3JA72+SejsZZjudS
8cMRpKtfSr5PGijvg61CXUG6MAZcq9rvT1AE4b3Ta7jCJwDBS2GcVSJnMtxLUqWU
stqcPUwg/lrSq5necfUPOJF5VLzN0HHhxIsPdvf1rmhDKSuj/9LQlqcHx64b//Hy
VEVuit7d8uLxXXlW1IuJ68O2kGlLX08UdBtbIIwHW/hbImoWn1zDlH3fCW6THM9Y
KTVClPsveGvhpLLlIRPka4LQ+kbyc2uB4Ap8PHuHbj14SiBH0A6y1cD4KYrB4cb5
gIZDbjS74U0biCV8PamaSexlWdG4HiHNLu0IfqpMlUMlr/+SgZoiB8NEJSSajvnE
lFhahSdx09lnWSIw8oogQbcL4jsdlP+SXoAM1/YmltZ/jXmggvopXApCfyw9xbbO
A2cbCuVuAss=
=4t08
-----END PGP SIGNATURE-----
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Transports

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On Tue, May 31, 2005 at 11:20:56AM -0400, Alec Warner wrote:
> Brian Harring wrote:
> Mostly was looking at a unified transport lib, with connection
> abstractions, which is basically what we have now, but lacks SCP/RSYNC
> support, and I think people would want that functionality, Remote repos
> with rsync for proto fex.  That way the remote repo code only depends on
> Transports and all the proto mess is abstracted away.  Maybe just keep
> em seperate and copy the rsync code?  I kind of like the single vs multi
> approach now that I think about it more :P
Unifying the actual 'transports' crap into transports would make 
sense, although I'd still posit a wrapper layer over whatever 
transport layer in use would be required; iow, transports/rsync, but 
sync/rsync still that imports portage.transports.rsync ..
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]