Re: [gentoo-dev] [RFC] SRC_URI behaviour

["Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org>]

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

On 06/15/2013 08:24 PM, Zac Medico wrote:
> On 06/15/2013 06:05 AM, Michał Górny wrote:
>> Dnia 2013-06-15, o godz. 15:56:53
>> "Vadim A. Misbakh-Soloviov" <mva@mva.name> napisał(a):
>>
>>> And, moreover, I guess, SRC_URI can even be used for VCS:
>>>
>>> SRC_URI="
>>>     git+ssh://github.com/lol/moo.git
>>>     hg+ssh://bitbucket.org/lol/moo
>>>     svn+ssh://assembla.com/lol/moo
>>> "
>>
>> It simply can't work. Don't even try to implement, it's waste of time.
>> Just grep the tree, see how various packages use VCS-es. There's too
>> many differences, too many needs and -- most importantly -- VCS-es
>> change over time much more quickly than, say, unpackers.
>>
>> Even *if* we get a SRC_URI VCS support that works for all consumers,
>> and that'd be awfully hard to do properly, it will eventually stop
>> being 'good enough' and require further changes. It will just become
>> never-ending story for a minor benefit.
> 
> How about it we add a src_fetch phase, so that the VCS intricacies can
> be delegated to ebuilds/eclasses (like they are now, but without having
> to abuse src_unpack). If we include a way for src_fetch to communicate
> changes in VCS revisions to the package manager, then we'll be able to
> integrate functionality like smart-live-rebuild directly into the
> package manager (as discussed in bug 182028 [1]).
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=182028

+1 on src_fetch in or out of the context of this thread.

+1 on more granular fetch/mirror restrictions

+-0 on VCS in SRC_URI, as I already stated I'm fine with the current
functionality (aside from a vast desire for src_fetch phase).

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRvc4cAAoJEKXdFCfdEflK990P/267Ej2p26SvRGItzFHtHakH
EwDEQcLxfykfqs1p1AWjR2O9e7ZvW7PaF9EyFdypY0MxAu0faB24ek4OKGD4842L
VbkQFXRjSOu1e+bLvQERofiVJ2/qSJZmg/phBsLwQiT0GVTm6ZXykZHSjfyTSALG
6ip+bhwUnYGGmxs8oudb7abBy7HfqhFlA6GTnyonqeRXre4QxfWFi1Yup/mRFuWp
XFwEoBe9t/95DBiXfjbvO5b6rlVEsChXuxELDUgP1dTdXTYKVRohs0lU6uZqlJkz
RY+8p8bJDsZas0Ucw7+7ePb93mH+XCKz5bvMrz2YhEM//NTOC6QY9+F6iy/NevTp
FNJeBCYUNKPpGzy4bm1649vDCqG51WK9iG8qtYO5G0y2QpkGZugUfALwalXK7L3M
eThjhlGrn0LZvGXxkYNtHgimFg3VWDJXJLHipMkP5dUqC5t4HEaEqgdGTCpzwuka
IUAahKdFLd3EZBlc3MHkYwuzfa0/MayOFiMcHKVV2+ONa5FcwkO8Rg6QJk5Xb7A1
NpPU87VampYERtaNcJKVACl8wR8Pltg4Y5xyz5Dgs+ga/gLvun6VePPO3WvKrAsS
UirS6VqysSEFaZTFotW0LAN6N8+Mll90gjRRgJxaQcGy1IiZ7VXYGzb8Q9nRWL9n
1PD6mk8hNr9C3aV14QzM
=7DTn
-----END PGP SIGNATURE-----