This was already mentioned in bug #80015 back in 2005...
'emerge -f' does nothing for e.g. CVS-based ebuilds, as it is embedded in src_unpack.
'emerge -f <cvs_based_package>'
<fails because sources aren't there>
This has bitten me several times in the past. When handling many packages at once, there's no easy way to tell *if* one of the packages is affected by this. You think you downloaded all you needed for a day's worth of compiling, but instead one of the first packages fails due to missing sources and your system spends the day idling...
What would be your solution? Would `emerge -f world` need to fail?
This bug report will probably go the way of bug #80015 if you don't provide any kind of solution to the problem.
We'd have to mark the ebuilds with some sort of metadata, such as PROPERTIES, and the ebuilds would have to implement a function that performs the fetch. Current ebuilds use src_unpack which is inappropriate for this purpose.
Rather than a PROPERTIES for "I have src_fetch_extra", it'd probably be useful to have a special package manager generated cached metadata key containing all the phases that are specified by the ebuild. DEFINED_PHASES="pkg_setup src_compile src_test", say. This would also let the package manager avoid having to exclusively run pkg_* phases for ebuilds that use the default, empty pkg_*.
Yeah, the DEFINED_PHASES idea makes sense. I suppose we can retroactively add a new src_fetch phase to existing EAPIs for this purpose, if it's not required to be supported. We could make src_fetch support mandatory in a new EAPI if necessary.
I'd be inclined to do src_fetch_extra (let's not call it src_fetch -- that'll give people the idea it's ok to use it to replace SRC_URI) purely as a new EAPI thing. Otherwise ebuilds will have to do some fairly messy hacks to work out whether or not the new phase has been run.
DEFINED_PHASES can go in retroactively and optionally for all EAPIs without any difficulty. We'd need to have some way of telling the difference between "DEFINED_PHASES isn't implemented" and "this ebuild defines no phases", though. Could just shove a - in there...
I can write up a proposal for DEFINED_PHASES if you like -- it's something I want for Paludis for other nefarious purposes anyway.
Yes, a DEFINED_PHASES proposal would be nice.
> What would be your solution? Would `emerge -f world` need to fail?
Of course not!
To be precise and working with a 'real' example, I would expect that...
'ebuild /usr/portage/media-tv/v4l-dvb-hg/v4l-dvb-hg-0.1-r2.ebuild fetch'
would actually *fetch* the sources (which it does not), and
'ebuild /usr/portage/media-tv/v4l-dvb-hg/v4l-dvb-hg-0.1-r2.ebuild unpack'
to *NOT* require an online connection.
As far as I can see, this would require an internal reorganization of the cvs.eclass (and other repository access eclasses), so that cvs_fetch() (and equivalents) are actually called during the *fetch* stage instead of the *unpack* stage.
*** Bug 352686 has been marked as a duplicate of this bug. ***
Not that I'm biting my nails about this one, but is there *any* progress on it?
I'm not aware of any progress. Meanwhile, you might want to check if smart-live-rebuild can help:
*** Bug 433868 has been marked as a duplicate of this bug. ***
*** Bug 433858 has been marked as a duplicate of this bug. ***
*** Bug 433860 has been marked as a duplicate of this bug. ***
*** Bug 433862 has been marked as a duplicate of this bug. ***
*** Bug 433866 has been marked as a duplicate of this bug. ***
I believe that this is pretty much a duplicate of bug 481434. Resolving it in that direction because the newer bug has a cleaner history.
*** This bug has been marked as a duplicate of bug 481434 ***
(In reply to Martin Baute from comment #9)
> Not that I'm biting my nails about this one, but is there *any* progress on
I am well aware that this bug is open since almost a decade. However, we are a volunteers' project. So, if you want a certain feature, you can either:
1) provide an implementation and a spec yourself,
2) convince others that this is important and has high priority, so that they do the work, or
3) hire someone to work on it.