Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Portage Developer (http://www.linux-archive.org/gentoo-portage-developer/)
-   -   Allow emerge to continue emerging unaffected packages on failure. (http://www.linux-archive.org/gentoo-portage-developer/102413-allow-emerge-continue-emerging-unaffected-packages-failure.html)

Brian 06-07-2008 03:43 PM

Allow emerge to continue emerging unaffected packages on failure.
 
There are a few emerge wrapper scripts that do what you want. emwrap.sh
is one, I believe update-world or named something like that is another.
Also (I'm prejudiced here) porhole is a portage gui frontend that queues
up the packages individually and lets you pause, move queue entries,
restart the queue, edit USE flags, etc.. The upgrades view also
separates all upgradeable packages into system, sets, world,
dependencies and lets you choose the ones to upgrade.

On Sat, 2008-06-07 at 11:13 -0400, Jason Cipriani wrote:
> I do not always have the chance (or sometimes the desire) to update
> packages often enough to keep the updates small. So frequently, when I
> emerge -u world, for example, there's 100-200 packages to update. This
> also can happen if I change certain USE flags and use -N.
>
> The problem is, since it's time consuming it's generally something I
> need to run over night to avoid any down time. Inevitably, when I come
> back in the morning, however, I'll see something like (I've trimmed
> off the [ok] to keep the lines short):
>
> >>> Emerging (12 of 183) net-print/cups-1.3.7-r1 to /
> * cups-1.3.7-source.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...
> * checking ebuild checksums ;-) ...
> * checking auxfile checksums ;-) ...
> * checking miscfile checksums ;-) ...
> * checking cups-1.3.7-source.tar.bz2 ;-) ...
> >>> cfg-update-1.8.2-r1: Skipping checksum index updating...
>
> * In order to have cups working with avahi zeroconf support, you need
> * to have net-dns/avahi emerged with "mdnsresponder-compat" in your
> USE
> * flag. Please add that flag, re-emerge avahi, and then emerge cups
> again.
>
>
> In that example, the fix is simple -- follow the instructions and try
> emerge -u again. Unfortunately that also means it costs another day,
> as I can't really do that again until the next evening (and, in rarer
> cases, it leaves the system unstable if it's in a half-updated state
> that breaks certain dependencies). For every package this happens to,
> that is one extra day. In most cases this happens to 1-4 packages,
> meaning I generally have to reserve the better part of a week to
> update packages.
>
> If package A depends on package B, it is reasonable to fail and not
> build package A if package B fails. However, I am 99% sure that the
> remaining 171 packages I had to update did not depend on cups (to use
> that example). It is not reasonable for emerge to fail to update
> things like gcc and ati-drivers if cups fails. It is also not
> reasonable to stop emerge for a reason like "another package may use
> avahi and that's the one you need to fix" -- as in that case a simple
> emerge -N would take care of the minimal set of packages effected by
> that change.
>
> What I would like to see is a command line option to emerge that
> enables the following simple behavior:
>
> - If package A fails to build, display the error and move package A
> and all packages that depend on it to the *end* of the update queue,
> but do not exit.
> - If a package fails to build for the second time (i.e. it's already
> been tried and moved), *then* display error and exit as normal.
>
> I can think of other more complex behaviors that might make this more
> "convenient", but I believe anything more than that is unnecessary. I
> think this is a simple solution that mitigates most of the problem.
> That will allow the unaffected packages (which, in my experience, is
> the vast majority of packages in most cases) to continue building, and
> effectively defers the error until the last possible minute. Then a
> user running emerge fixes the error and reruns emerge; but only the
> smaller set of affected packages still remains to be built.
>
> For me, this would reduce updating my system from a week-long process
> to just one day -- update the majority overnight, and if any fail it's
> likely that the remaining packages can be fixed and updated in a
> reasonable amount of time the following day.
>
> Jason
>
--
Brian <dol-sen@telus.net>

--
gentoo-portage-dev@lists.gentoo.org mailing list

06-08-2008 01:08 AM

Allow emerge to continue emerging unaffected packages on failure.
 
On Sat, Jun 07, 2008 at 11:13:16AM -0400, Jason Cipriani wrote:

> What I would like to see is a command line option to emerge that enables the
> following simple behavior:

Pardon me if I am wrong, but I want this too, and to me the simplest
analogy is to make. If some targets fail, make keeps on building the
ones it can, until it is left with no buildable targets. I too have
developed a wrapper using --resume --skipfirst, but that feels like a
kluge. What I would like is an emerge option to generate a Makefile
for output (-M looks available on a quick man check). Then instead of
emerge -ptuvDN, I would use -MtuvDN, and run make at my leisure. I am
incredibly naive about the inner workings of portage, but since it has
dependencies, it does not seem entirely farfetched to generate a Makefile.

--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
--
gentoo-portage-dev@lists.gentoo.org mailing list

Zac Medico 06-08-2008 01:29 AM

Allow emerge to continue emerging unaffected packages on failure.
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

felix@crowfix.com wrote:
> On Sat, Jun 07, 2008 at 11:13:16AM -0400, Jason Cipriani wrote:
>
>> What I would like to see is a command line option to emerge that enables the
>> following simple behavior:
>
> Pardon me if I am wrong, but I want this too, and to me the simplest
> analogy is to make. If some targets fail, make keeps on building the
> ones it can, until it is left with no buildable targets. I too have
> developed a wrapper using --resume --skipfirst, but that feels like a
> kluge. What I would like is an emerge option to generate a Makefile
> for output (-M looks available on a quick man check). Then instead of
> emerge -ptuvDN, I would use -MtuvDN, and run make at my leisure. I am
> incredibly naive about the inner workings of portage, but since it has
> dependencies, it does not seem entirely farfetched to generate a Makefile.
>

Why not just take the features from make and add them to portage
itself? That way you can just treat the portage configurations as
the "Makefile".

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

iEYEARECAAYFAkhLNeIACgkQ/ejvha5XGaP+rgCfaBPJpBwYy8kB68jIX0rkSmzN
zX0An2JlRjd7Bah0ZtTBNMftEAE/jq+H
=8OeD
-----END PGP SIGNATURE-----
--
gentoo-portage-dev@lists.gentoo.org mailing list

06-08-2008 01:54 AM

Allow emerge to continue emerging unaffected packages on failure.
 
On Sat, Jun 07, 2008 at 06:29:08PM -0700, Zac Medico wrote:
> felix@crowfix.com wrote:
> > Pardon me if I am wrong, but I want this too, and to me the simplest
> > analogy is to make. If some targets fail, make keeps on building the
> > ones it can, until it is left with no buildable targets. I too have
> > developed a wrapper using --resume --skipfirst, but that feels like a
> > kluge. What I would like is an emerge option to generate a Makefile
> > for output (-M looks available on a quick man check). Then instead of
> > emerge -ptuvDN, I would use -MtuvDN, and run make at my leisure. I am
> > incredibly naive about the inner workings of portage, but since it has
> > dependencies, it does not seem entirely farfetched to generate a Makefile.
> >
>
> Why not just take the features from make and add them to portage
> itself? That way you can just treat the portage configurations as
> the "Makefile".

If you mean make the entire portage tree into one big Makefile, how do
you represent sources which change to trigger making? Chaning USE
flags is another trigger, and various options to emerge have their own
effect on which builds are needed.

If you mean imitate make's build process in portage, that seems like a
lot of wheel reinventing.

An advantage of generating Makefile output is it can replace the -p
pretend option, and it lets you fine tune it by editing. For
instance, my system right now wants to throw out mDNSmumble needed by
KDE something in favor of avahi needed by the latest pidgin. So I
save emerge output, edit away the avahi build and pidgin rebuild, and
have a specific list to build. I cannot let emerge have its way; it
blocks on avahi and mDNSmumble. A Makefile would have the same
conflict, but make would ignore that part and do the rest, or I could
edit out the conflict.

--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
--
gentoo-portage-dev@lists.gentoo.org mailing list

Zac Medico 06-08-2008 03:50 AM

Allow emerge to continue emerging unaffected packages on failure.
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

felix@crowfix.com wrote:
> On Sat, Jun 07, 2008 at 06:29:08PM -0700, Zac Medico wrote:
>> felix@crowfix.com wrote:
>>> Pardon me if I am wrong, but I want this too, and to me the simplest
>>> analogy is to make. If some targets fail, make keeps on building the
>>> ones it can, until it is left with no buildable targets. I too have
>>> developed a wrapper using --resume --skipfirst, but that feels like a
>>> kluge. What I would like is an emerge option to generate a Makefile
>>> for output (-M looks available on a quick man check). Then instead of
>>> emerge -ptuvDN, I would use -MtuvDN, and run make at my leisure. I am
>>> incredibly naive about the inner workings of portage, but since it has
>>> dependencies, it does not seem entirely farfetched to generate a Makefile.
>>>
>> Why not just take the features from make and add them to portage
>> itself? That way you can just treat the portage configurations as
>> the "Makefile".
>
> If you mean make the entire portage tree into one big Makefile, how do
> you represent sources which change to trigger making? Chaning USE
> flags is another trigger, and various options to emerge have their own
> effect on which builds are needed.
>
> If you mean imitate make's build process in portage, that seems like a
> lot of wheel reinventing.
>
> An advantage of generating Makefile output is it can replace the -p
> pretend option, and it lets you fine tune it by editing. For
> instance, my system right now wants to throw out mDNSmumble needed by
> KDE something in favor of avahi needed by the latest pidgin. So I
> save emerge output, edit away the avahi build and pidgin rebuild, and
> have a specific list to build. I cannot let emerge have its way; it
> blocks on avahi and mDNSmumble. A Makefile would have the same
> conflict, but make would ignore that part and do the rest, or I could
> edit out the conflict.
>

Why not modify the ebuilds to resolve the conflicts (use
PORTDIR_OVERLAY)? Then if your modifications are worth sharing, you
can submit them back to Gentoo.

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

iEYEARECAAYFAkhLVwsACgkQ/ejvha5XGaO+ogCgmIlbhy9mEy9wE4BwSAtAs1/8
mOUAn2FTElKwEYiMuSxjNNDyf/i1milC
=e+09
-----END PGP SIGNATURE-----
--
gentoo-portage-dev@lists.gentoo.org mailing list


All times are GMT. The time now is 09:23 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.