FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-04-2012, 04:43 PM
Michał Górny
 
Default src_fetch() phase function to support VCS fetching

Hello,

As Sid Hayn raised today on #gentoo-portage, it would be useful to
finally have portage able to fetch updates from VCS-es independently
of src_unpack(). This could be used, for example, on machines
temporarily connected to the network -- one would then fetch files
while connected to the network, and perform the updates later.

There are a few ways how we could handle that but the cleanest and most
universal one seems to be defining a src_fetch() phase function
in a future EAPI.

In the EAPIs supporting src_fetch(), that phase function would be used
by PM when requesting the files to be fetched. A default_src_fetch()
will be declared as well, providing implementation-defined code
fetching files like they are fetched now. Older EAPIs will simply
always use that default.

The phase function would be disjoint from the normal merge process,
much like pkg_pretend(). In portage, it will be called as 'portage'
user if FEATURES=userfetch is enabled.

VCS eclasses supporting separated fetching would define two phase
functions:
- src_fetch() which would be responsible for fetching updates,
- src_unpack() which would be responsible for checking out the source
to work directory.

The remaining issue is handling dependencies on the tools necessary to
do fetching. For default_src_fetch(), we can assume that the package
manager provides the necessary tools. For custom src_fetch(), we would
need either to:

1) require satisfying whole DEPEND when fetching -- probably pointless,
as it will make --fetchonly almost impossible when doing initial
installs;

2) introduce a new dependency type (please do not get into details how
we do it -- we will discuss that another time, at the moment please
just keep it as 'new dependency type') -- and we probably end up
having a switch for --fetchonly without installing deps (thus
omitting packages where they are not satisfied), and with deps;

3) [ugly!] assume that src_fetch() should check for its deps and fail
if they are not satisfied. If that's mostly for live ebuilds, it may
be acceptable. Then the package manager will just have one 'fetch
failed' on --fetchonly (or early pre-fetch), and it will have to
invoke src_fetch() after satisfying the deps, before src_unpack().

What do you think? What are your ideas, suggestions?

--
Best regards,
Michał Górny
 
Old 09-04-2012, 05:02 PM
"Rick "Zero_Chaos" Farina"
 
Default src_fetch() phase function to support VCS fetching

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

On 09/04/2012 12:43 PM, Michał Górny wrote:
> Hello,
>
> As Sid Hayn raised today on #gentoo-portage, it would be useful to
If you insist on using real names mine is Rick ;-)
> finally have portage able to fetch updates from VCS-es independently
> of src_unpack(). This could be used, for example, on machines
> temporarily connected to the network -- one would then fetch files
> while connected to the network, and perform the updates later.
>
> There are a few ways how we could handle that but the cleanest and most
> universal one seems to be defining a src_fetch() phase function
> in a future EAPI.
>
> In the EAPIs supporting src_fetch(), that phase function would be used
> by PM when requesting the files to be fetched. A default_src_fetch()
> will be declared as well, providing implementation-defined code
> fetching files like they are fetched now. Older EAPIs will simply
> always use that default.
>
> The phase function would be disjoint from the normal merge process,
> much like pkg_pretend(). In portage, it will be called as 'portage'
> user if FEATURES=userfetch is enabled.
>
> VCS eclasses supporting separated fetching would define two phase
> functions:
> - src_fetch() which would be responsible for fetching updates,
> - src_unpack() which would be responsible for checking out the source
> to work directory.
>
> The remaining issue is handling dependencies on the tools necessary to
> do fetching. For default_src_fetch(), we can assume that the package
> manager provides the necessary tools. For custom src_fetch(), we would
> need either to:
>
> 1) require satisfying whole DEPEND when fetching -- probably pointless,
> as it will make --fetchonly almost impossible when doing initial
> installs;
>
> 2) introduce a new dependency type (please do not get into details how
> we do it -- we will discuss that another time, at the moment please
> just keep it as 'new dependency type') -- and we probably end up
> having a switch for --fetchonly without installing deps (thus
> omitting packages where they are not satisfied), and with deps;
>
> 3) [ugly!] assume that src_fetch() should check for its deps and fail
> if they are not satisfied. If that's mostly for live ebuilds, it may
> be acceptable. Then the package manager will just have one 'fetch
> failed' on --fetchonly (or early pre-fetch), and it will have to
> invoke src_fetch() after satisfying the deps, before src_unpack().
>
> What do you think? What are your ideas, suggestions?
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQRjQeAAoJEKXdFCfdEflKdDAP/jyV8+NwEBX+etKq7e+qzbVg
oIgjqOLfqYEmbEkO9WMsUltsf8YATy9zGB1itRiLUb5v+eptjE Dvp2dx/AA4YVio
RLYwtMBJsESXd6d+3PbCTeoZHTZwb7ue6yY+qC0auyC4mD6nrk DY8swungcDwFHN
GZ99gAtRnQ5h8+phrKHyWzePTkBN5+32GCIn2XfRwMo+T0tGyT eMGqYfPJPlEu0y
LNJmdBU0TfzE7N8QA4sp/IDQQvBmZNpH6aQM+zkJWpvBUXBATdIPZZHBAy55TWaJ
t9KxiHD6XF/h0ShlTIpsbfSj31FTil2l/LfhAQdXSrB4GPxLaoovOJb2vl9L+ZyP
QJclNeL1kNaOO1MIm20tGJOV6Wh0iHsn/fJlbh4YYn4PaNF+F+UXyp69uGcniuCe
PxFC/aosq39LoFRrZdyRfx3DWPXnhYfcFWRwEDosa/Qb/Mbljs+BZRRPIB2Y8ItV
9j5WokM6BkNPNeoNnaS1JvCaac7xiurizs7IaXxfYC5q8aZja1 OdDrV9Jh7KxIUe
q8rsKMk6y9KqGvSBfW3Y9JDgIdUUG8x0bVM/j9+gqOtPH5uFgPRnZxX/Hfb0+1J5
iLjFXgwLl2AtEuflY07KfKB9xyEV58x8gkCo/BUX8Y8E6re5/4o+kNiArQL2Z+YS
SOD2BmvyVHOlurug9Lq4
=FOao
-----END PGP SIGNATURE-----
 
Old 09-04-2012, 05:02 PM
Michael Mol
 
Default src_fetch() phase function to support VCS fetching

On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Hello,
>
> As Sid Hayn raised today on #gentoo-portage, it would be useful to
> finally have portage able to fetch updates from VCS-es independently
> of src_unpack(). This could be used, for example, on machines
> temporarily connected to the network -- one would then fetch files
> while connected to the network, and perform the updates later.
>
> There are a few ways how we could handle that but the cleanest and most
> universal one seems to be defining a src_fetch() phase function
> in a future EAPI.
>
> In the EAPIs supporting src_fetch(), that phase function would be used
> by PM when requesting the files to be fetched. A default_src_fetch()
> will be declared as well, providing implementation-defined code
> fetching files like they are fetched now. Older EAPIs will simply
> always use that default.
>
> The phase function would be disjoint from the normal merge process,
> much like pkg_pretend(). In portage, it will be called as 'portage'
> user if FEATURES=userfetch is enabled.
>
> VCS eclasses supporting separated fetching would define two phase
> functions:
> - src_fetch() which would be responsible for fetching updates,
> - src_unpack() which would be responsible for checking out the source
> to work directory.

The 'checking out' language for src_unpack() sounds like it assumes a
DVCS such as mercurial or git. What about cvs or svn, where fetching
is also checking out? (This is probably a trivial thing to clear up,
though.)

Also, where would the local copy go? distfiles? It's common for
distfiles to be stored on, e.g. an NFS mount, so you may need to be
careful not to place repositories there which have filesystem
semantics that are disagreeable to NFS. (The only example I know of
off the top of my head is svn, where the documentation warns against
using the dbd backend on top of NFS.)

Other common remote mounts (such as cifs) may have restrictions that
could force munging of filenames, too, and VCS infrastructures (or
even unpacked checkouts with strange filenames) placed on those
filesystems may have unanticipated results.

It may be helpful to have some kind of adapter mount in place, or even
generate a tarball of the local copy and store that instead. (That'd
be problematic if multiple boxes were modifying the local copy on the
same share, but that's obviously problematic anyway.)

--
:wq
 
Old 09-04-2012, 05:05 PM
"Rick "Zero_Chaos" Farina"
 
Default src_fetch() phase function to support VCS fetching

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

On 09/04/2012 12:43 PM, Michał Górny wrote:
> Hello,
>
> As Sid Hayn raised today on #gentoo-portage, it would be useful to
> finally have portage able to fetch updates from VCS-es independently
> of src_unpack(). This could be used, for example, on machines
> temporarily connected to the network -- one would then fetch files
> while connected to the network, and perform the updates later.
>
> There are a few ways how we could handle that but the cleanest and most
> universal one seems to be defining a src_fetch() phase function
> in a future EAPI.
>
> In the EAPIs supporting src_fetch(), that phase function would be used
> by PM when requesting the files to be fetched. A default_src_fetch()
> will be declared as well, providing implementation-defined code
> fetching files like they are fetched now. Older EAPIs will simply
> always use that default.
>
> The phase function would be disjoint from the normal merge process,
> much like pkg_pretend(). In portage, it will be called as 'portage'
> user if FEATURES=userfetch is enabled.
>
> VCS eclasses supporting separated fetching would define two phase
> functions:
> - src_fetch() which would be responsible for fetching updates,
> - src_unpack() which would be responsible for checking out the source
> to work directory.
>
> The remaining issue is handling dependencies on the tools necessary to
> do fetching. For default_src_fetch(), we can assume that the package
> manager provides the necessary tools. For custom src_fetch(), we would
> need either to:
>
> 1) require satisfying whole DEPEND when fetching -- probably pointless,
> as it will make --fetchonly almost impossible when doing initial
> installs;
>
> 2) introduce a new dependency type (please do not get into details how
> we do it -- we will discuss that another time, at the moment please
> just keep it as 'new dependency type') -- and we probably end up
> having a switch for --fetchonly without installing deps (thus
> omitting packages where they are not satisfied), and with deps;
>
> 3) [ugly!] assume that src_fetch() should check for its deps and fail
> if they are not satisfied. If that's mostly for live ebuilds, it may
> be acceptable. Then the package manager will just have one 'fetch
> failed' on --fetchonly (or early pre-fetch), and it will have to
> invoke src_fetch() after satisfying the deps, before src_unpack().

I believe the easiest (and honestly most sane) method is to simply have
src_fetch in the live classes check for needed deps and die (with a
"please emerge blah") if deps are not found. Adding something like
FDEPEND just seems to be getting way too crazy on the dependency tree
AND would require things to build during fetch-only which doesn't make
sense.

Thanks,
Zero
>
> What do you think? What are your ideas, suggestions?
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQRjTjAAoJEKXdFCfdEflKGPoP+wYhzeFNcX O9Lv4qm5/oPXuC
RIrCs2q6erWxowFbiTO//XILVbiH1nHBWx/uJV9S0hTM+dBRIh/zZaCXy5PYnLrK
dTKiHgmpNPgTQ41QGI7BZl4lQFGLgGfdJnCncSTLmLZQtMGwXD 4jZ8SQ/QE1wbwK
rpHtYQ/Z5kUKFJG25MRFtFZ2ifZQVpVIPmmrFfyDh+1l9Oh8AtF6XKZTr iwX1ppG
osPz8jo2XtoYejqvD0kFEZwc5C7FKmULYyrB+tcl5dmOgf60Lv cDTBkUGi7U2ewk
DWhVoLX0zXWMZfoEi3c6GRsJgZ81yXIMfPC+SUYipdfBvdH6iW YuxfgJpSioUtbV
s4xC4IyOGQehnt8OAe5PpHHJcqxlDVXidmVz0sKkmJB3dM6rIs amiNZajmKVrnyh
1zle8g4XBP8AFg/fB+OiOSuYNoI5GnC2D/rp7zAtajl+0GtVWvApPUFEa0DP8LlR
bYXMIGpx+LAi9rYlEdNs3tW1C4OVjZpCKYU7cjNO15f2ZOVX4W NmAWtRmpoG6O5l
zL1Mv6DRgdtoITfYfogupZBgjynHsCzKL1Mb2skqtmJ853ZjV4 HGgXqxcica12O7
EoJ65EU5rrzCGSUz5rqunNwK9A11VBjxXWJ/e29NKt2vACxRuiwMXkl7EK2a/oCA
pTBk5q6CvQFJCyzw2bee
=ueCf
-----END PGP SIGNATURE-----
 
Old 09-04-2012, 05:23 PM
Michał Górny
 
Default src_fetch() phase function to support VCS fetching

On Tue, 4 Sep 2012 13:02:36 -0400
Michael Mol <mikemol@gmail.com> wrote:

> On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > Hello,
> >
> > As Sid Hayn raised today on #gentoo-portage, it would be useful to
> > finally have portage able to fetch updates from VCS-es independently
> > of src_unpack(). This could be used, for example, on machines
> > temporarily connected to the network -- one would then fetch files
> > while connected to the network, and perform the updates later.
> >
> > There are a few ways how we could handle that but the cleanest and
> > most universal one seems to be defining a src_fetch() phase function
> > in a future EAPI.
> >
> > In the EAPIs supporting src_fetch(), that phase function would be
> > used by PM when requesting the files to be fetched. A
> > default_src_fetch() will be declared as well, providing
> > implementation-defined code fetching files like they are fetched
> > now. Older EAPIs will simply always use that default.
> >
> > The phase function would be disjoint from the normal merge process,
> > much like pkg_pretend(). In portage, it will be called as 'portage'
> > user if FEATURES=userfetch is enabled.
> >
> > VCS eclasses supporting separated fetching would define two phase
> > functions:
> > - src_fetch() which would be responsible for fetching updates,
> > - src_unpack() which would be responsible for checking out the
> > source to work directory.
>
> The 'checking out' language for src_unpack() sounds like it assumes a
> DVCS such as mercurial or git. What about cvs or svn, where fetching
> is also checking out? (This is probably a trivial thing to clear up,
> though.)

They either stay with src_unpack() or do 'cvs up' in src_fetch()
and just copy files over in src_unpack(). Anyway, that's what they do
now -- update the copy in distfiles/cvs-src and then copy it.

> Also, where would the local copy go? distfiles? It's common for
> distfiles to be stored on, e.g. an NFS mount, so you may need to be
> careful not to place repositories there which have filesystem
> semantics that are disagreeable to NFS. (The only example I know of
> off the top of my head is svn, where the documentation warns against
> using the dbd backend on top of NFS.)

The actual code will be eclass-dependent, so it will go whatever it
goes now. No magic, no exherbo. Just plain phase function.

--
Best regards,
Michał Górny
 
Old 09-04-2012, 05:24 PM
"Rick "Zero_Chaos" Farina"
 
Default src_fetch() phase function to support VCS fetching

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

On 09/04/2012 01:02 PM, Michael Mol wrote:
> On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> Hello,
>>
>> As Sid Hayn raised today on #gentoo-portage, it would be useful to
>> finally have portage able to fetch updates from VCS-es independently
>> of src_unpack(). This could be used, for example, on machines
>> temporarily connected to the network -- one would then fetch files
>> while connected to the network, and perform the updates later.
>>
>> There are a few ways how we could handle that but the cleanest and most
>> universal one seems to be defining a src_fetch() phase function
>> in a future EAPI.
>>
>> In the EAPIs supporting src_fetch(), that phase function would be used
>> by PM when requesting the files to be fetched. A default_src_fetch()
>> will be declared as well, providing implementation-defined code
>> fetching files like they are fetched now. Older EAPIs will simply
>> always use that default.
>>
>> The phase function would be disjoint from the normal merge process,
>> much like pkg_pretend(). In portage, it will be called as 'portage'
>> user if FEATURES=userfetch is enabled.
>>
>> VCS eclasses supporting separated fetching would define two phase
>> functions:
>> - src_fetch() which would be responsible for fetching updates,
>> - src_unpack() which would be responsible for checking out the source
>> to work directory.
>
> The 'checking out' language for src_unpack() sounds like it assumes a
> DVCS such as mercurial or git. What about cvs or svn, where fetching
> is also checking out? (This is probably a trivial thing to clear up,
> though.)
>
> Also, where would the local copy go? distfiles? It's common for
> distfiles to be stored on, e.g. an NFS mount, so you may need to be
> careful not to place repositories there which have filesystem
> semantics that are disagreeable to NFS. (The only example I know of
> off the top of my head is svn, where the documentation warns against
> using the dbd backend on top of NFS.)
>
> Other common remote mounts (such as cifs) may have restrictions that
> could force munging of filenames, too, and VCS infrastructures (or
> even unpacked checkouts with strange filenames) placed on those
> filesystems may have unanticipated results.
>
> It may be helpful to have some kind of adapter mount in place, or even
> generate a tarball of the local copy and store that instead. (That'd
> be problematic if multiple boxes were modifying the local copy on the
> same share, but that's obviously problematic anyway.)
>

All the live eclasses already drop a checkout (or whatever term you
like) of the repo in /usr/portage/distfiles. What we are talking about
here is separating the "download/checkout into /usr/portage/distfiles"
from the "copy from /usr/portage/distfiles to ${S}". Making this two
separate phases would allow a reasonably sane "emerge -f blah" support
to fetch the live sources before build.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQRjk9AAoJEKXdFCfdEflKeocQAJgSMaycMk vmdalYWUBU4lRJ
eNilSxWoMAuln+1FMRv9HxavQCMzkw/h9o3Lwy75Kv2+Z/MZy60caG7yplexSKEf
Z3apTwU1Cbj7WasDNkNRXgoHHsn55Fnr28lueFmcAlvMWDnBV0 TmXCYFiRh961hN
7Co3wbHT4ahk1TTTURFDoWbE2R24e1UJFzrWRRO4oyoIDqPqOI OqhR+4Nnl5vsXa
/UQmvIqgzxlWgdjeaWceQxgexPt0g+ZwFUFIF6FhL3xqoF6kokB j64VxPRAgK05X
x78LSsul+A0H6sAU4S9e5CmZekxFyNanF3PJ5aZaAfp8dPTWaU FIhJHh3jDFktdT
zaO1LVpEOVnUenuV6XgpETN8XxThZHzXFRokuyR3Aza41/p3eg/jo07DGmUBLRP2
fu9h/ZVwrcPixgpTNd2+8YhxIxuoka7CmJiVb4ncAJ/Yp95G64dM57DXf46rKPTC
6LX/5jQgXcR+WbQswLumZJ+EJ7aIzGhJRFGXZmbNvWVrzFxfB7vtgU l6NUsKmzTo
gffrxrZexzlnvkCThrdM1C89BdAdkWATICiAAEkf2P9gzEdtB+ p65VBqYcNzFc+Q
X9kw+X6lnAn6D/KqJdSAG9plhjRuZ9JTGnZ/ZlucyP7uVnmHV5+NOVn5MYvZ/Sso
z2F4QPIJi3C9LQkOSyKF
=vy05
-----END PGP SIGNATURE-----
 
Old 09-04-2012, 05:32 PM
Zac Medico
 
Default src_fetch() phase function to support VCS fetching

On 09/04/2012 10:05 AM, Rick "Zero_Chaos" Farina wrote:
> I believe the easiest (and honestly most sane) method is to simply have
> src_fetch in the live classes check for needed deps and die (with a
> "please emerge blah") if deps are not found. Adding something like
> FDEPEND just seems to be getting way too crazy on the dependency tree
> AND would require things to build during fetch-only which doesn't make
> sense.

I think it's nicer to have FDEPEND because it makes the deps more
complete, so the package manager can bail out when necessary, without
even executing src_fetch. In the case of --fetchonly the package manager
could simply bail out if the deps are not installed (like how it bails
out for --buildpkgonly when the deps aren't installed).
--
Thanks,
Zac
 
Old 09-04-2012, 07:56 PM
Ian Stakenvicius
 
Default src_fetch() phase function to support VCS fetching

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/09/12 01:32 PM, Zac Medico wrote:
> On 09/04/2012 10:05 AM, Rick "Zero_Chaos" Farina wrote:
>> I believe the easiest (and honestly most sane) method is to
>> simply have src_fetch in the live classes check for needed deps
>> and die (with a "please emerge blah") if deps are not found.
>> Adding something like FDEPEND just seems to be getting way too
>> crazy on the dependency tree AND would require things to build
>> during fetch-only which doesn't make sense.
>
> I think it's nicer to have FDEPEND because it makes the deps more
> complete, so the package manager can bail out when necessary,
> without even executing src_fetch. In the case of --fetchonly the
> package manager could simply bail out if the deps are not installed
> (like how it bails out for --buildpkgonly when the deps aren't
> installed).

Just looking into the future here; would things like archivers or
other helpers used by src_unpack move to FDEPEND as well? or would
this be limited solely to tools that data transfer?



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBGXQYACgkQ2ugaI38ACPDKGwEAlvqkQHBv2v DtGfYNYrIIMIV9
1le8HgtXRhIu9FOhw1EA/3m1xc4zNcWMslK6RiV5sn4mBVXUQt6Ry2m/Nar+ccFq
=DqcL
-----END PGP SIGNATURE-----
 
Old 09-04-2012, 08:05 PM
"Rick "Zero_Chaos" Farina"
 
Default src_fetch() phase function to support VCS fetching

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

On 09/04/2012 03:56 PM, Ian Stakenvicius wrote:
> On 04/09/12 01:32 PM, Zac Medico wrote:
>> On 09/04/2012 10:05 AM, Rick "Zero_Chaos" Farina wrote:
>>> I believe the easiest (and honestly most sane) method is to
>>> simply have src_fetch in the live classes check for needed deps
>>> and die (with a "please emerge blah") if deps are not found.
>>> Adding something like FDEPEND just seems to be getting way too
>>> crazy on the dependency tree AND would require things to build
>>> during fetch-only which doesn't make sense.
>
>> I think it's nicer to have FDEPEND because it makes the deps more
>> complete, so the package manager can bail out when necessary,
>> without even executing src_fetch. In the case of --fetchonly the
>> package manager could simply bail out if the deps are not installed
>> (like how it bails out for --buildpkgonly when the deps aren't
>> installed).
>
> Just looking into the future here; would things like archivers or
> other helpers used by src_unpack move to FDEPEND as well? or would
> this be limited solely to tools that data transfer?

We are talking about things required for src_fetch (the download) so no,
things required for src_unpack have no real place in this as far as I am
concerned.
>
>
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQRl8nAAoJEKXdFCfdEflKoA0P/152JYx2/62tou9kcUCEILkz
DXGfO5bY+A1DYrCsVAR9H7C4dzmrULU0JNjUl3nMpGFKXMAvWQ bai2uDICMECZVg
QCwHVzxyHD9TzdVAyp928dtn/FtnPvaUV8WHIugFuaZZM/mmACsyEYxFqusMXu51
KkMzs1F9TatL3uoAMuvT0KLiMWHmxw6OrmMrqRX1T7gP4AIy7c D5h8v7DOzWORLQ
x12/HGAA2HLDgfhwrNymRs+OIqSLXE54DmAfvOglB6Jfw/I/N6HoY1PQ1vZaW7jU
P+t2l7VbRsINmHUk+tbl+7A5F2XBE5GphSh8oIN7yuToSwtbst lGFmTGhb/V0gpM
HUpI5v/6B40fc+DgEuAMAZjhUBT+1YIbIO9WVUaXN/I9JBA22FBZSm4qu59qWg/U
DX+Jhul9M+A5QPdNBios0K5BYxFXamx/i52w/361NdLV2Onn1zHQT95oC7RKOGJG
fZu6PhtkW7Z/CaYSja7TKa8H5pl/+Bj5Mgz7cGlwz41AP4Q6+omfnxlLf+iJME07
rBfKe4RuhZuUXamu+SfW7OdNY8Zqm9skSGw1HbHFVHDQIXKtt8 Pv9tr1m364h+W9
r6SUE1xdJaCbtzh2/ajpu9EIVLoVuW/NEFvQIMd7wn3R2PTKgNHOnkLB6c8j/qaa
nWe+jCpIt2uSd2Syceqh
=4kd2
-----END PGP SIGNATURE-----
 
Old 09-04-2012, 08:09 PM
Michał Górny
 
Default src_fetch() phase function to support VCS fetching

On Tue, 04 Sep 2012 15:56:54 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 04/09/12 01:32 PM, Zac Medico wrote:
> > On 09/04/2012 10:05 AM, Rick "Zero_Chaos" Farina wrote:
> >> I believe the easiest (and honestly most sane) method is to
> >> simply have src_fetch in the live classes check for needed deps
> >> and die (with a "please emerge blah") if deps are not found.
> >> Adding something like FDEPEND just seems to be getting way too
> >> crazy on the dependency tree AND would require things to build
> >> during fetch-only which doesn't make sense.
> >
> > I think it's nicer to have FDEPEND because it makes the deps more
> > complete, so the package manager can bail out when necessary,
> > without even executing src_fetch. In the case of --fetchonly the
> > package manager could simply bail out if the deps are not installed
> > (like how it bails out for --buildpkgonly when the deps aren't
> > installed).
>
> Just looking into the future here; would things like archivers or
> other helpers used by src_unpack move to FDEPEND as well? or would
> this be limited solely to tools that data transfer?

src_fetch() only. Archivers belong to src_unpack(), which belongs to
the main phase function cycle -> DEPEND.


--
Best regards,
Michał Górny
 

Thread Tools




All times are GMT. The time now is 07:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org