Official way to do rolling update (Was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

Official way to do rolling update (Was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[yac]

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

On Sun, 03 Nov 2013 11:02:31 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

[snip]
> > 
> > Afaik there is no official way to update gentoo, is there?
> 
> It's always been "emerge -avuND world"
[snip]

Is this documented annywhere? I have a hard time finding it. I can see
it mentioned eg. in man emerge in -c option but that's not good enough.

Even if it is documented, I think it would be very helpfull to have
such a way implemented as "kind of option" to emerge like `emerge
--standard-ugrade` that would just alias to -uaNDv or possibly leverage
sets like `emerge @upgrade`

-- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Official way to do rolling update (Was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Daniel Campbell]

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

On 11/03/2013 10:15 PM, yac wrote:
> On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon
> <alan.mckinnon@gmail.com> wrote:
> 
> [snip]
>>> 
>>> Afaik there is no official way to update gentoo, is there?
>> 
>> It's always been "emerge -avuND world"
> [snip]
> 
> Is this documented annywhere? I have a hard time finding it. I can
> see it mentioned eg. in man emerge in -c option but that's not good
> enough.
> 
> Even if it is documented, I think it would be very helpfull to
> have such a way implemented as "kind of option" to emerge like
> `emerge --standard-ugrade` that would just alias to -uaNDv or
> possibly leverage sets like `emerge @upgrade`
> 

You could emulate this yourself by setting up an environment variable
to pass to emerge, or use an alias like I do:

alias sysupdate='emerge -avuDN --with-bdeps=y @world'

(Note: I should probably extend this to accept $1 args, in case I want
to add `-t` or something)

If you wanted something to cover more bases, you could make a script
to do the above in addition to revdep-rebuild, python-updater,
etc-update, and so on. Given the power and flexibility of
portage/emerge and the extremely broad variety of needs that Gentoo
meets, I believe it would be somewhat wasted work to add the option
when users are already expected to read manpages and the Handbook.
Perhaps -avuND should be made more obvious in a place or two in the
documentation as a sort of compromise.

Just my two cents,

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

iQEcBAEBAgAGBQJSd1/TAAoJEJUrb08JgYgH364H/AqgN1bSxltry7kZbAWqT7hb
CtNuCNKv5cChmUuq8YmEmdq1B8fJK6YQ0OieNt19MHQsOe9GWml1lMqfXzzmV63w
GgsIxIs5QjNtfIYeDUVqJpxzmNcFRndJjp7AEgFiiujtl42p5OQGJfJVjAf197tR
DPju9kZMbO62KyUD7pn5xc6T6RBW8xzsniRaBXAR3C3bLaJtFVHO7Dtk8ki6DELf
ES+vszWdMFCP6GiOULuHSkTnsnrPAEhEHdHcRDSTHOcpMlTx4qEO43dK1f1FkOGx
oXIVvgB8LNP2DgBmWeqK63UBP/01zl4XuKjHFtHJpWJluE6z1PaspF216HP7esc=
=XaI0
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Duncan]

Daniel Campbell posted on Mon, 04 Nov 2013 02:50:27 -0600 as excerpted:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/03/2013 10:15 PM, yac wrote:
>> On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon
>> <alan.mckinnon@gmail.com> wrote:
>> 
>> [snip]
>>>> 
>>>> Afaik there is no official way to update gentoo, is there?
>>> 
>>> It's always been "emerge -avuND world"
>> [snip]
>> 
>> Is this documented annywhere? I have a hard time finding it. I can see
>> it mentioned eg. in man emerge in -c option but that's not good enough.

Read the handbook lately? =:^)

Handbook, part 2, Working with Gentoo, Chapter 1, A Portage Introduction, 
Doc_chapter 3, Maintaining Software (this is the amd64 link):

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?
part=2&chap=1#doc_chap3

Look under the heading Updating your System.  That starts with...

emerge --update --ask world

... then discusses --deep, --withbdeps=y, and --newuse, so the example 
full update is ...

emerge --update --deep --with-bdeps=y --newuse world

--ask and --pretend are discussed in the same doc_chapter as well, as is 
-v (tho inconsistently, I don't see the long-option --verbose discussed, 
as it is for the others).

--depclean, --search and --unmerge are discussed in that chapter too, as 
is gentoolkit with equery and revdep-rebuild.  About the only thing 
missing is sets, and they're missing from working with portage (part 3) 
AFAICT as well, most likely because the handbooks simply haven't been 
updated for sets yet.

>> Even if it is documented, I think it would be very helpfull to have
>> such a way implemented as "kind of option" to emerge like `emerge
>> --standard-ugrade` that would just alias to -uaNDv or possibly leverage
>> sets like `emerge @upgrade`


This has been discussed before.  Zac could give you a summary and 
possibly point you at the thread, I'm sure.

I believe the reason it wasn't done is because the default options 
setting was added instead.  Well that and the fact that (as covered 
below), I guess most users setup their own scripts/aliases at some point, 
at which point the existence of something that general-purpose default 
built-in becomes moot.

> You could emulate this yourself by setting up an environment variable to
> pass to emerge, or use an alias like I do:
> 
> alias sysupdate='emerge -avuDN --with-bdeps=y @world'
> 
> (Note: I should probably extend this to accept $1 args, in case I want
> to add `-t` or something)
> 
> If you wanted something to cover more bases, you could make a script to
> do the above in addition to revdep-rebuild, python-updater, etc-update,
> and so on. Given the power and flexibility of portage/emerge and the
> extremely broad variety of needs that Gentoo meets, I believe it would
> be somewhat wasted work to add the option when users are already
> expected to read manpages and the Handbook. Perhaps -avuND should be
> made more obvious in a place or two in the documentation as a sort of
> compromise.

++

FWIW, I have a whole set of short, often 2-4 letter aliases/scripts that 
take care of the various options, as I'm lazy and find reaching for the 
"-" key difficult.  Most of them are broken down into ea* and ep* 
variants, for ask and pretend, and the default is oneshot so as not to 
pollute the world file (which is normally empty anyway, as is @system for 
that matter as I negated it in my profile, everything's in sets, tho I 
sometimes use the worldfile as a sort of "package purgatory" when I want 
to try something out and keep it updated, but am not sure I want it in 
one of my permanent sets yet).

Then there's esyn, which syncs both the gentoo tree and layman, as well 
as automatically handling ebuild patching and redigesting using a tree 
similar to the /etc/portage/patches/ tree, and does an automatic fetch 
deep world before its done.

Then there's the ead (depclean) and ear (revdep-rebuild) variants, as 
well as epc to lookup changelogs, ept* for tree, and eal for @smart-live-
rebuild.

Completing the set are eup (etc-update) and envup (env-update).

I have a similar set, but starting with k* instead of e*, for automatic 
mainline kernel fetching, building, etc.  There are git-kernel commands 
and tarball-kernel commands, tho I've not used the latter in a few years 
so it could well be bitrotted.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[yac]

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

On Mon, 4 Nov 2013 09:51:32 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Daniel Campbell posted on Mon, 04 Nov 2013 02:50:27 -0600 as
> excerpted:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 11/03/2013 10:15 PM, yac wrote:
> >> On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon
> >> <alan.mckinnon@gmail.com> wrote:
> >> 
> >> [snip]
> >>>> 
> >>>> Afaik there is no official way to update gentoo, is there?
> >>> 
> >>> It's always been "emerge -avuND world"
> >> [snip]
> >> 
> >> Is this documented annywhere? I have a hard time finding it. I can
> >> see it mentioned eg. in man emerge in -c option but that's not
> >> good enough.
> 
> Read the handbook lately? =:^)
> 
> Handbook, part 2, Working with Gentoo, Chapter 1, A Portage
> Introduction, Doc_chapter 3, Maintaining Software (this is the amd64
> link):
> 
> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?
> part=2&chap=1#doc_chap3
> 
> Look under the heading Updating your System.  That starts with...
> 
> emerge --update --ask world
> 
> ... then discusses --deep, --withbdeps=y, and --newuse, so the
> example full update is ...
> 
> emerge --update --deep --with-bdeps=y --newuse world
> 
> --ask and --pretend are discussed in the same doc_chapter as well, as
> is -v (tho inconsistently, I don't see the long-option --verbose
> discussed, as it is for the others).
> 
> --depclean, --search and --unmerge are discussed in that chapter too,
> as is gentoolkit with equery and revdep-rebuild.  About the only
> thing missing is sets, and they're missing from working with portage
> (part 3) AFAICT as well, most likely because the handbooks simply
> haven't been updated for sets yet.

Yes, there is describes what are possible ways to update the system and
what criteria goes into selection of the packages to update but not
which one is recommended, generaly for regular update. Could be
helpful for newbs and to avoid doubt even between more experienced
users.

I think only -u world could be used to do updates. (possible
--with-bdeps could be recommended too, for better security until users
find out about glsa-check, though I think it is limited to packages
that are believed to be widely deployed.

 
> >> Even if it is documented, I think it would be very helpfull to have
> >> such a way implemented as "kind of option" to emerge like `emerge
> >> --standard-ugrade` that would just alias to -uaNDv or possibly
> >> leverage sets like `emerge @upgrade`
> 
> 
> This has been discussed before.  Zac could give you a summary and 
> possibly point you at the thread, I'm sure.
> 
> I believe the reason it wasn't done is because the default options 
> setting was added instead.  Well that and the fact that (as covered 
> below), I guess most users setup their own scripts/aliases at some
> point, at which point the existence of something that general-purpose
> default built-in becomes moot.

I expected some people to do this now, but I never found it worth
anything unless it could deal with all the
(perl|python|haskell|whatnot)-updaters and revdep-rebuild and such.
It would be nice-to-have it as part of emerge for the reasons above and
not having to 

> > You could emulate this yourself by setting up an environment
> > variable to pass to emerge, or use an alias like I do:
> > 
> > alias sysupdate='emerge -avuDN --with-bdeps=y @world'
> > 
> > (Note: I should probably extend this to accept $1 args, in case I
> > want to add `-t` or something)
> > 
> > If you wanted something to cover more bases, you could make a
> > script to do the above in addition to revdep-rebuild,
> > python-updater, etc-update, and so on. Given the power and
> > flexibility of portage/emerge and the extremely broad variety of
> > needs that Gentoo meets, I believe it would be somewhat wasted work
> > to add the option when users are already expected to read manpages
> > and the Handbook. Perhaps -avuND should be made more obvious in a
> > place or two in the documentation as a sort of compromise.
> 
> ++
> 
> FWIW, I have a whole set of short, often 2-4 letter aliases/scripts
> that take care of the various options, as I'm lazy and find reaching
> for the "-" key difficult.  Most of them are broken down into ea* and
> ep* variants, for ask and pretend, and the default is oneshot so as
> not to pollute the world file (which is normally empty anyway, as is
> @system for that matter as I negated it in my profile, everything's
> in sets, tho I sometimes use the worldfile as a sort of "package
> purgatory" when I want to try something out and keep it updated, but
> am not sure I want it in one of my permanent sets yet).
> 
> Then there's esyn, which syncs both the gentoo tree and layman, as
> well as automatically handling ebuild patching and redigesting using
> a tree similar to the /etc/portage/patches/ tree, and does an
> automatic fetch deep world before its done.
> 
> Then there's the ead (depclean) and ear (revdep-rebuild) variants, as 
> well as epc to lookup changelogs, ept* for tree, and eal for
> @smart-live- rebuild.
> 
> Completing the set are eup (etc-update) and envup (env-update).
> 
> I have a similar set, but starting with k* instead of e*, for
> automatic mainline kernel fetching, building, etc.  There are
> git-kernel commands and tarball-kernel commands, tho I've not used
> the latter in a few years so it could well be bitrotted.
> 

Sooo, basicly you have defined buttload of aliases, somehow managed to
remember these nonsensical names and actually did not save any
keystrokes, because most linux users heard of tab completion and use it
succesfuly to complete commands and their arguments. Cool story bro.


-- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Dale]

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

yac wrote:
> On Mon, 4 Nov 2013 09:51:32 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>> Daniel Campbell posted on Mon, 04 Nov 2013 02:50:27 -0600 as
>> excerpted:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 11/03/2013 10:15 PM, yac wrote:
>>>> On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon
>>>> <alan.mckinnon@gmail.com> wrote:
>>>>
>>>> [snip]
>>>>>>
>>>>>> Afaik there is no official way to update gentoo, is there?
>>>>>
>>>>> It's always been "emerge -avuND world"
>>>> [snip]
>>>>
>>>> Is this documented annywhere? I have a hard time finding it. I can
>>>> see it mentioned eg. in man emerge in -c option but that's not
>>>> good enough.
>>
>> Read the handbook lately? =:^)
>>
>> Handbook, part 2, Working with Gentoo, Chapter 1, A Portage
>> Introduction, Doc_chapter 3, Maintaining Software (this is the amd64
>> link):
>>
>> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?
>> part=2&chap=1#doc_chap3
>>
>> Look under the heading Updating your System.  That starts with...
>>
>> emerge --update --ask world
>>
>> ... then discusses --deep, --withbdeps=y, and --newuse, so the
>> example full update is ...
>>
>> emerge --update --deep --with-bdeps=y --newuse world
>>
>> --ask and --pretend are discussed in the same doc_chapter as well, as
>> is -v (tho inconsistently, I don't see the long-option --verbose
>> discussed, as it is for the others).
>>
>> --depclean, --search and --unmerge are discussed in that chapter too,
>> as is gentoolkit with equery and revdep-rebuild.  About the only
>> thing missing is sets, and they're missing from working with portage
>> (part 3) AFAICT as well, most likely because the handbooks simply
>> haven't been updated for sets yet.
>
> Yes, there is describes what are possible ways to update the system and
> what criteria goes into selection of the packages to update but not
> which one is recommended, generaly for regular update. Could be
> helpful for newbs and to avoid doubt even between more experienced
> users.
>
> I think only -u world could be used to do updates. (possible
> --with-bdeps could be recommended too, for better security until users
> find out about glsa-check, though I think it is limited to packages
> that are believed to be widely deployed.
>
> 

But after a person has used Gentoo a while, they figure out what process
leads to the most stable update process.  They also figure out what
defaults to add to make.conf as well.  For that, it is as Duncan and
Alan describe.  Both have been using Gentoo for quite a while.  I been
using Gentoo for a good ten years.  I installed from Gentoo 1.4 I
think.  Here is mine in make.conf:

EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=30 --keep-going -v -j10
--quiet-build=n -1"

For my updates, I use this:

emerge -uaDN world

The only way to get a more stable system is to do a emerge -e world and
update that way.  At least that has been my experience so far.  If Zac
adds some other nifty feature, then I may add to the above as needed. 
For the past few years, that has resulted in as stable a system as I can
get.  I do from time to time run emerge -e world just for giggles when I
have something acting odd and can't put my finger on the issue. 
Sometimes, that fixes it, sometimes not.

Again, most of this comes from experience.  The handbook explains it
then the user figures it out from there.

My $0.02 worth.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 5447 bytes --]

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Tom Wijsman]

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

On Mon, 04 Nov 2013 06:06:52 -0600
Dale <rdalek1967@gmail.com> wrote:

> But after a person has used Gentoo a while, they figure out what
> process leads to the most stable update process.

Do they? What do you consider a stable update process?

I come across users on a daily basis which

 - haven't upgraded their system lately because they're not good at it;
 - get into unclear slot conflicts locking them out of updates;
 - some build failure disallows their dependency graph from completing;
 - managed to finally update, but don't know about depclean;
 - managed to finally depclean, but don't know about eclean.

It involves a lot of prior knowledge, manual checking and what in order
to be able to update the system; I wouldn't label this "stable", but
rather "dependent on the person updating it" and to some extent even
"dependent on whether the person memorized all the docs and/or gets
helped or get it told in the support channels".

There are some improvements possible in these situations; I'm planning
to discuss some ideas and write some patches where possible, and I
hope other people jump on the bandwagon to help improve user experience.

That doesn't mean I consider it bad or that we need to go hand holding.

> The only way to get a more stable system is to do a emerge -e world
> and update that way.  At least that has been my experience so far.

I have never needed this; I wonder whether there exists an example case
for this, I only see this used when someone changes compiler / flags
and wants to ensure the whole system turns into rice. *

> If Zac adds some other nifty feature, then I may add to the above as
> needed. For the past few years, that has resulted in as stable a
> system as I can get.  I do from time to time run emerge -e world just
> for giggles when I have something acting odd and can't put my finger
> on the issue. Sometimes, that fixes it, sometimes not.
> 
> Again, most of this comes from experience.  The handbook explains it
> then the user figures it out from there.

 * http://funroll-loops.info/

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Rich Freeman]

On Mon, Nov 4, 2013 at 7:28 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Mon, 04 Nov 2013 06:06:52 -0600
> Dale <rdalek1967@gmail.com> wrote:
>
>> But after a person has used Gentoo a while, they figure out what
>> process leads to the most stable update process.
>
> Do they? What do you consider a stable update process?
>
> I come across users on a daily basis which...

I would love to see a simple way to invoke emerge such that it just
"does the right thing" in updating the system.  Its behavior would
always be considered subject to change (scripts should use the long
options if they don't just want the latest automagic behavior).

I see this as having several benefits:

1.  It is newbie friendly.  Anybody can understand apt-get update,
apt-get upgrade.  If I told you what I invoked to do my daily updates
on Gentoo it would start a religious war on whether I'm doing it
right.

2.  It is supportable.  If a developer pushes out a commit without a
news item such that a stable user runs the standard update command
before the commit and after it and the second update fails, then that
is a valid bug.  I'm not suggesting that all such bugs are
preventable/etc, but it does help get rid of the whole "you're holding
it wrong" debate.

3.  It is maintainable.  When new portage features arise they can be
added to the default behavior when appropriate, without the need to
get everybody to change their command lines.

4.  It is a standard.  Gentoo is all about being able to deviate from
the standards.  However, there is still value in suggesting a best
practice.

Rich

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Dale]

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

Tom Wijsman wrote:
> On Mon, 04 Nov 2013 06:06:52 -0600
> Dale <rdalek1967@gmail.com> wrote:
>
>> But after a person has used Gentoo a while, they figure out what
>> process leads to the most stable update process.
>
> Do they? What do you consider a stable update process?

I consider it stable when things work as they should except for known
bugs upstream.  Obviously if there is a known bug upstream then that bug
will likely filter right on through to Gentoo.  That said, if the Gentoo
devs can correct a issue, they do so but that is not always the case
either.

>
>
> I come across users on a daily basis which
>
>  - haven't upgraded their system lately because they're not good at it;
>  - get into unclear slot conflicts locking them out of updates;
>  - some build failure disallows their dependency graph from completing;
>  - managed to finally update, but don't know about depclean;
>  - managed to finally depclean, but don't know about eclean.
>
> It involves a lot of prior knowledge, manual checking and what in order
> to be able to update the system; I wouldn't label this "stable", but
> rather "dependent on the person updating it" and to some extent even
> "dependent on whether the person memorized all the docs and/or gets
> helped or get it told in the support channels".
>
> There are some improvements possible in these situations; I'm planning
> to discuss some ideas and write some patches where possible, and I
> hope other people jump on the bandwagon to help improve user experience.
>
> That doesn't mean I consider it bad or that we need to go hand holding.

It does require prior knowledge which is why I said what I did.  I used
to do emerge -u world way back when.  That would SOMETIMES lead to
issues because it may not go deep enough.  Then I added -D which helped
but from time to time would still miss something.  So, I added the
backtrack to make.conf.  That improved things even more.  Over time, I
realized that I needed to add the -N option so it got added to the
command.  As it is now, I have that knowledge.  I learned some of that
the hard way.

You are right, it does require prior knowledge and as a user gets that
knowledge, they likely end up where Alan, Duncan and myself are.  That
would be emerge -uaDN world.  Right now, that has lead me to the most
stable OS.  When it doesn't, I do a emerge -e world if nothing else
fixes the issue.  That doesn't happen as much as it used to because
either Zac is tweaking portage or devs are doing better on the ebuilds. 
Heck, it could be both since both need to work well to get a good end
result.

>
>> The only way to get a more stable system is to do a emerge -e world
>> and update that way.  At least that has been my experience so far.
>
> I have never needed this; I wonder whether there exists an example case
> for this, I only see this used when someone changes compiler / flags
> and wants to ensure the whole system turns into rice. *

I have needed this more than once in the past.  I would run into a
problem and recompiling the obvious packages didn't correct the issue. 
Doing a emerge -e world would fix the issue.  Obviously something fell
through the cracks that my usual command would miss but the -e would
catch since it does all packages.  I never reported the issue since I
don't know what specifically fixed the issue.  There is no way for a
person to figure out if it is a portage issue, ebuild issue or some
other issue.  I didn't see the point in filing a bug because there is no
way to track down the source of the problem.

This is my experience.  By all means, if you do something different and
it works for you, do it your way.  I'm going to continue doing what
works for me.  If someone asks me how I do things, I'll recommend the
same command/settings I use just like I'm sure some other old timers
will do.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 5345 bytes --]

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Tom Wijsman]

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

On Mon, 04 Nov 2013 14:02:28 -0600
Dale <rdalek1967@gmail.com> wrote:

> You are right, it does require prior knowledge and as a user gets that
> knowledge, they likely end up where Alan, Duncan and myself are.  That
> would be emerge -uaDN world.

And from there you can continue; like adding -vt --unordered-display
and the list goes onto get a lot more detail, it can be handy to see
what depends on what such that you don't look at a flat list wondering
where a dependency came from. I haven't looked further at all the more
specific parameters one can pass; but well, surely there's some
objective and/or subjective improvement still possible there.

> I have needed this more than once in the past.  I would run into a
> problem and recompiling the obvious packages didn't correct the
> issue. Doing a emerge -e world would fix the issue.

Usually I debug / troubleshoot it for long enough to avoid that; but
well, yeah, depending on the situation `emerge -e @world` could take
a lot less time. Especially on a new Gentoo install where this might be
more likely to happen as you often change things in the early days...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Dale]

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

Tom Wijsman wrote:
> On Mon, 04 Nov 2013 14:02:28 -0600
> Dale <rdalek1967@gmail.com> wrote:
>
>> You are right, it does require prior knowledge and as a user gets that
>> knowledge, they likely end up where Alan, Duncan and myself are.  That
>> would be emerge -uaDN world.
>
> And from there you can continue; like adding -vt --unordered-display
> and the list goes onto get a lot more detail, it can be handy to see
> what depends on what such that you don't look at a flat list wondering
> where a dependency came from. I haven't looked further at all the more
> specific parameters one can pass; but well, surely there's some
> objective and/or subjective improvement still possible there.

The -v option is already in my make.conf file for portage but I do type
it in out of habit sometimes.  I do sometimes add -t if I think it will
help.  Sometimes it does, sometimes it doesn't.   My point still
remains, emerge -uaDN world has given me the most stable system so far. 
Removing any of those options results in issues and I end up going back
to the command I should have used to begin with.


>
>
>> I have needed this more than once in the past.  I would run into a
>> problem and recompiling the obvious packages didn't correct the
>> issue. Doing a emerge -e world would fix the issue.
>
> Usually I debug / troubleshoot it for long enough to avoid that; but
> well, yeah, depending on the situation `emerge -e @world` could take
> a lot less time. Especially on a new Gentoo install where this might be
> more likely to happen as you often change things in the early days...
>

When I run into a issue and post on -user and no one has a fix, I assume
that I'm not going to find a fix on my own either.  Duncan, Alan, Neil
and others are MUCH more experienced than I am on the code part.  So, if
I need something fixed, emerge -e world may be the only option.  Speed
may not matter since anything else could still leave me with a not so
stable issue.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 3048 bytes --]

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Alan McKinnon]

On 04/11/2013 14:28, Tom Wijsman wrote:
>> The only way to get a more stable system is to do a emerge -e world
>> > and update that way.  At least that has been my experience so far.
> I have never needed this; I wonder whether there exists an example case
> for this, I only see this used when someone changes compiler / flags
> and wants to ensure the whole system turns into rice. *
> 


I've used this once or twice over the years to take care of inexplicable
instability, the last time being right in the middle of kmail2/akonadi
upheaval. I think it was in the KDE4.4 days.

I strongly suspect the actual cause was inconsistencies around plug-in
modules - the only thing I know of that portage and tools like
revdep-rebuild can't really detect.

I must stress that it's an exceptionally blunt hammer of a tool and not
to be used lightly. It's really the very very last resort, only suitable
when the cost of my troubleshooting time is more than the cost of cpu
cycles over a weekend.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Tom Wijsman]

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

On Mon, 4 Nov 2013 11:26:32 +0100
yac <yac@gentoo.org> wrote:

> On Mon, 4 Nov 2013 09:51:32 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
> > FWIW, I have a whole set of short, often 2-4 letter aliases/scripts
> > that take care of the various options
>
> Sooo, basicly you have defined buttload of aliases, somehow managed to
> remember these nonsensical names and actually did not save any
> keystrokes, because most linux users heard of tab completion and use
> it succesfuly to complete commands and their arguments. Cool story
> bro.

Cool story guys.

Just like how MSOffice 2007 had tons of shortcuts to remember whereas
they got rid of that in MSOffice 2010 by intuitive context relevant
shortcuts; yet, people had memorized the shortcuts and are much quicker
than having to learn all the positions in the new intuitive Ribbon bar.
I didn't learn those shortcuts; so, I am quick with the Ribbon bar...

Or why do

    ebuild name-1.ebuild clean manifest unpack
    ebuild name-2.ebuild clean manifest unpack
    diff -urN /var/tmp/portage/name-{1,2}/workdir/*
    # ^ Actually, you would need to source S="..." twice.

which requires a ton of tabs when I can just do `ediff 1 2`? I can
memorize it, but perhaps others need more short commands and can't.

You'll find out that people end up using both approaches; so, please
let's not get into detailed opinions, it is just a matter of choice.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Duncan]

yac posted on Mon, 04 Nov 2013 11:26:32 +0100 as excerpted:

> Sooo, basicly you have defined buttload of aliases, somehow managed to
> remember these nonsensical names and actually did not save any
> keystrokes, because most linux users heard of tab completion and use it
> succesfuly to complete commands and their arguments. Cool story bro.

Such "nonsense" puts me in good company, given "nonsense" such as "mv" 
"cp" and "rm", in the best Unix tradition!  So thanks for the compliment! 
=:^)

Just as beginner Unix admins /think/ "move" when they type mv, until mv 
becomes its own concept and thinking "move" is the long way around, I 
/thought/ "emerge ask world" when I typed eaw, until familiarity made eaw 
the normal concept, and "emerge --ask (-NuDv) @world" became the long way 
around I seldom gave much thought to any longer.

As for tab-completion, it only takes a bit of shell-script to add the tab-
completion already available for emerge, to my ea*/ep* variants as well, 
and they're tab-completed with (other) options and package names exactly  
as if I had typed/completed out the longer form.  Drop that in the same 
autocomplete location and I'm good to go! =:^)

Nobody says you have to use it, and I was in fact arguing that everybody 
develops their own such shortcuts over time.  My solution's not for 
everybody and apparently not for you, but that's fine, because it's 
uniquely custom designed for me! =:^)  But what makes Unix/Linux/Gentoo 
great is that this same level of unique custom design is available and 
exposed to everyone, for their own use as they see fit. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Martin Vaeth]

Duncan <1i5t5.duncan@cox.net> wrote:
>
> and the default is oneshot

I would always recommend to put -1 into EMERGE_DEFAULT_OPTS;
you can still use --select if you really want a new package in a
word file: after the first installation this should happen rather rarely
(and you can still use -n --select later on if you forgot it and
realize that depclean wants to remove it).

(Also there is the world script from the mv overlay which,
among other things, keeps/compares a backup of your world/world_set
file, just in case...)

> Then there's esyn, which syncs both the gentoo tree and layman, as well
> as automatically handling ebuild patching and redigesting

You can use eix-sync for that: If properly configured it handles
tree and layman sync, eix-update (and eix-remote if required) and
also has all sorts of hooks which can be used to call your
patching/redigesting scripts; if you need an exceptional usage
(e.g. to skip gentoo/layman syncing and/or the patching hooks)
you can pass parameters to eix-sync.

The advantage is that you will probably have a better behaviour
in case some of the tasks fail...

> I have a similar set, but starting with k* instead of e*, for automatic
> mainline kernel fetching, building, etc.

This is rather cumbersome, since you should have different
permissions for building and installing (if you use the
recommended way to build into a separate KBUILD_OUTPUT
with e.g. portage permissions).
Except for fetching, you might want to use the kernel script
from the mv overlay.

[gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Duncan]

Martin Vaeth posted on Mon, 04 Nov 2013 11:17:49 +0000 as excerpted:

> Duncan <1i5t5.duncan@cox.net> wrote:
>>
>> and the default is oneshot
> 
> I would always recommend to put -1 into EMERGE_DEFAULT_OPTS;
> you can still use --select if you really want a new package in a word
> file: after the first installation this should happen rather rarely (and
> you can still use -n --select later on if you forgot it and realize that
> depclean wants to remove it).

I imagine were emerge being written today, -1 /would/ be the default, and 
there'd be an option like --select to add to the @world file if 
necessary.  That's actually the way I setup my scripts, with -1 the 
default, and an extra "2" suffix script variant that did add to the world 
file.  But backward compatibility being what it is, I guess by the time 
portage authors realized they had a backward default, they couldn't 
really fix it, except by something like EMERGE_DEFAULT_OPTS.

>> Then there's esyn, which syncs both the gentoo tree and layman, as well
>> as automatically handling ebuild patching and redigesting
> 
> You can use eix-sync for that [...]
> 
> The advantage is that you will probably have a better behaviour in case
> some of the tasks fail...

Again, if it were available (and something I knew about) back in the 
day... I might have ended up with that.

However, I've come to appreciate an advantage to writing one's own 
scripts -- bug fixing or adding new functionality is a *LOT* easier since 
you're already familiar with the code.  In fact, speaking from 
experience, adding support for a new feature to a script you've created 
yourself is often easier than figuring out the new config options for the 
same feature for an upstream script, when they add support for it!  Plus, 
you don't have to worry about learning new config options for new 
features you'll never use, since you simply don't code them in the first 
place. =:^)

The ebuild-patching tree and auto-redigest features were in fact recent 
adds, when I needed something that scaled better than one-off ebuild 
editing during the time gentoo/kde dropped support for USE=semantic-
desktop and I had to carry my own patches to kill it.  (FWIW, they've 
since reverted and offer USE=semantic-desktop again now, THANKS
gentoo/kde! =:^)

Similarly, adding git functionality to my existing kernel scripts wasn't 
difficult, and arguably easier to do since I knew the code, than trying 
to reverse engineer the new config options and perhaps the supporting 
code behind it, were I using an upstream solution that added git kernel 
support to existing helper scripts.

>> I have a similar set, but starting with k* instead of e*, for automatic
>> mainline kernel fetching, building, etc.
> 
> This is rather cumbersome, since you should have different permissions
> for building and installing (if you use the recommended way to build
> into a separate KBUILD_OUTPUT with e.g. portage permissions).
> Except for fetching, you might want to use the kernel script from the mv
> overlay.

Actually, both different building/installing permissions (via config file 
sudo option, tho I'll admit since I set that the option, running with 
that option turned off isn't tested, but the basic script infrastructure 
for it is there), and KBUILD_OUTPUT (setting in the config file) are 
already supported. =:^)

And talk about ease of adding functionality, when I setup my 32-bit 
netbook build chroot, it was just a few lines changed in the kernel 
scripts themselves, and a "dynamic config" line added to the config file 
(which is sourced, so accepts both var=val style and dynamic config 
script snippets) to auto-detect which system I was building for and set 
KBUILD_OUTPUT accordingly, thereby keeping the work dirs and config 
entirely separate, automatically, via "dynamic config".

Trivial feature-add, and now that it's there, if I suddenly needed to 
scale to 100 or 1000 different kernel configs, that'd be even more 
trivial (even just a config file change), if necessary by having the 
config file source yet another "separate-builds.conf" file with its own 
dynamic-config logic to choose between the different configs.

This sort of solidly sysadmin level helper/glue script is something Unix/
Linux/Gentoo is well optimized to make not only possible, but trivial, to 
implement, and I definitely put that feature to use! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Michael Orlitzky]

On 11/04/2013 04:46 PM, Duncan wrote:
> 
> I imagine were emerge being written today, -1 /would/ be the default, and 
> there'd be an option like --select to add to the @world file if 
> necessary.  That's actually the way I setup my scripts, with -1 the 
> default, and an extra "2" suffix script variant that did add to the world 
> file.  But backward compatibility being what it is, I guess by the time 
> portage authors realized they had a backward default, they couldn't 
> really fix it, except by something like EMERGE_DEFAULT_OPTS.
> 

Actually, this behavior has flipped back and forth three or four times
(silently!), to the detriment of my @world sets.

The last time I brought it up was in,

  https://bugs.gentoo.org/show_bug.cgi?id=397313

but you can chase the bug trail back to 2004. There are plenty of people
on both sides.

I haven't changed my mind, but the problem is "solved" here. I spend
hours writing metapackages for the things that I want recorded in @world
so that they can be differentiated from the things that were --updated
without --oneshot (which is easy to forget).

The servers that were alive during the silent changes in behavior were
physically retired.

[gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Duncan]

Michael Orlitzky posted on Mon, 04 Nov 2013 20:23:17 -0500 as excerpted:

> On 11/04/2013 04:46 PM, Duncan wrote:
>> 
>> I imagine were emerge being written today, -1 /would/ be the default,
>> and there'd be an option like --select to add to the @world file if
>> necessary.  That's actually the way I setup my scripts
>> 
> Actually, this behavior has flipped back and forth three or four times
> (silently!), to the detriment of my @world sets.

I guess that demonstrates the degree to which I use my scripts, as I 
wasn't even aware of that...

> [T]he problem is "solved" here. I spend
> hours writing metapackages for the things that I want recorded in @world
> so that they can be differentiated from the things that were --updated
> without --oneshot (which is easy to forget).

I jumped on sets for that, putting everything in sets and checking the 
world file occasionally so that if there's anything it it at all, it's 
either because I put it there specifically as a package purgatory, or 
because I forgot... but evidently I've used my scripts so consistently 
that I've never forgotten., as I've yet to find anything there I didn't 
deliberately put in package purgatory.

Actually, I ended up using sets back when I setup my netbook, as I needed 
some way to sort thru the main machine's world file and figure out what 
listings I wanted for the netbook and which not, and I was familiar with 
the then new sets feature from the kde overlay, and decided sets were the 
perfect way to category-sort everything, figuring out what I wanted on 
the netbook at the same time.

I don't update the netbook anything even close to as consistently, 
however, often ending up going a year or even two between updates 
(security isn't a big issue as I deliberately keep anything sensitive off 
the netbook already, and use it more offline than as as a NETbook in any 
case), but because I keep the sets identical except for #-commenting a 
package here or there on one side or the other, when I /do/ update it's a 
relatively simple matter to diff the sets along with the use file 
(separate and sourced from make.conf) and package.* files, updating the 
netbook's files based on the main machine's files as I go.

Then it's mostly a matter of iteratively updating what can be updated, 
skipping what can't as the jump is too large and other packages need 
updated first, dealing with the problems one at a time, until everything 
updated and I can once again do an emerge empty-tree world without issue.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Daniel Campbell]

On 11/04/2013 03:46 PM, Duncan wrote:
> Martin Vaeth posted on Mon, 04 Nov 2013 11:17:49 +0000 as excerpted:
> 
>> Duncan <1i5t5.duncan@cox.net> wrote:
>>>
>>> and the default is oneshot
>>
>> I would always recommend to put -1 into EMERGE_DEFAULT_OPTS;
>> you can still use --select if you really want a new package in a word
>> file: after the first installation this should happen rather rarely (and
>> you can still use -n --select later on if you forgot it and realize that
>> depclean wants to remove it).
> 
> I imagine were emerge being written today, -1 /would/ be the default, and 
> there'd be an option like --select to add to the @world file if 
> necessary.  That's actually the way I setup my scripts, with -1 the 
> default, and an extra "2" suffix script variant that did add to the world 
> file.  But backward compatibility being what it is, I guess by the time 
> portage authors realized they had a backward default, they couldn't 
> really fix it, except by something like EMERGE_DEFAULT_OPTS.
> 
>>> Then there's esyn, which syncs both the gentoo tree and layman, as well
>>> as automatically handling ebuild patching and redigesting
>>
>> You can use eix-sync for that [...]
>>
>> The advantage is that you will probably have a better behaviour in case
>> some of the tasks fail...
> 
> Again, if it were available (and something I knew about) back in the 
> day... I might have ended up with that.
> 
> However, I've come to appreciate an advantage to writing one's own 
> scripts -- bug fixing or adding new functionality is a *LOT* easier since 
> you're already familiar with the code.  In fact, speaking from 
> experience, adding support for a new feature to a script you've created 
> yourself is often easier than figuring out the new config options for the 
> same feature for an upstream script, when they add support for it!  Plus, 
> you don't have to worry about learning new config options for new 
> features you'll never use, since you simply don't code them in the first 
> place. =:^)
> 
> The ebuild-patching tree and auto-redigest features were in fact recent 
> adds, when I needed something that scaled better than one-off ebuild 
> editing during the time gentoo/kde dropped support for USE=semantic-
> desktop and I had to carry my own patches to kill it.  (FWIW, they've 
> since reverted and offer USE=semantic-desktop again now, THANKS
> gentoo/kde! =:^)
> 
> Similarly, adding git functionality to my existing kernel scripts wasn't 
> difficult, and arguably easier to do since I knew the code, than trying 
> to reverse engineer the new config options and perhaps the supporting 
> code behind it, were I using an upstream solution that added git kernel 
> support to existing helper scripts.
> 
>>> I have a similar set, but starting with k* instead of e*, for automatic
>>> mainline kernel fetching, building, etc.
>>
>> This is rather cumbersome, since you should have different permissions
>> for building and installing (if you use the recommended way to build
>> into a separate KBUILD_OUTPUT with e.g. portage permissions).
>> Except for fetching, you might want to use the kernel script from the mv
>> overlay.
> 
> Actually, both different building/installing permissions (via config file 
> sudo option, tho I'll admit since I set that the option, running with 
> that option turned off isn't tested, but the basic script infrastructure 
> for it is there), and KBUILD_OUTPUT (setting in the config file) are 
> already supported. =:^)
> 
> And talk about ease of adding functionality, when I setup my 32-bit 
> netbook build chroot, it was just a few lines changed in the kernel 
> scripts themselves, and a "dynamic config" line added to the config file 
> (which is sourced, so accepts both var=val style and dynamic config 
> script snippets) to auto-detect which system I was building for and set 
> KBUILD_OUTPUT accordingly, thereby keeping the work dirs and config 
> entirely separate, automatically, via "dynamic config".
> 
> Trivial feature-add, and now that it's there, if I suddenly needed to 
> scale to 100 or 1000 different kernel configs, that'd be even more 
> trivial (even just a config file change), if necessary by having the 
> config file source yet another "separate-builds.conf" file with its own 
> dynamic-config logic to choose between the different configs.
> 
> This sort of solidly sysadmin level helper/glue script is something Unix/
> Linux/Gentoo is well optimized to make not only possible, but trivial, to 
> implement, and I definitely put that feature to use! =:^)
> 

I'd be very interested in this kernel config script you have! I want to
set up a mini ITX system as a NAS some day, and since it runs an Intel
Atom, I'm likely going to be building the packages on my desktop.

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Peter Stuge]

Duncan wrote:
> I believe the reason it wasn't done is because the default options 
> setting was added instead.  Well that and the fact that (as covered 
> below), I guess most users setup their own scripts/aliases at some point, 
> at which point the existence of something that general-purpose default 
> built-in becomes moot.

Not if the built-in code saves a meaningful bit of code for each user.


//Peter

Re: Official way to do rolling update (Was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Tom Wijsman]

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

On Mon, 4 Nov 2013 05:15:18 +0100
yac <yac@gentoo.org> wrote:

> On Sun, 03 Nov 2013 11:02:31 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
> [snip]
> > > 
> > > Afaik there is no official way to update gentoo, is there?
> > 
> > It's always been "emerge -avuND world"
> [snip]
> 
> Is this documented annywhere? I have a hard time finding it. I can see
> it mentioned eg. in man emerge in -c option but that's not good
> enough.

Yeah, we do...

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#doc_chap3_sect5

So, we're not really trying to solve a problem here; yet we can improve
the situation so people don't have to manually retype the same chain of
commands everytime or rewrite their own shell alias or function.
 
> Even if it is documented, I think it would be very helpfull to have
> such a way implemented as "kind of option" to emerge like `emerge
> --standard-ugrade` that would just alias to -uaNDv or possibly
> leverage sets like `emerge @upgrade`

Yeah, I think everyone has implemented their own kind of alternative:

eupdate()
{
        emerge -uDN @system @world
        dispatch-conf
        etc-update
        emerge -uDN @system @world
        emerge -c && (
                eclean-dist -d
                eclean-pkg -d
                emerge @preserved-rebuild
        )
}

Others have worked together and put it into a handy tool:

http://weaver.gentooexperimental.org/update.html

It would indeed be nice to join efforts and have something that does to
updating what genkernel does to kernels, then get that into the
Portage tree and suggest it as an alternative to doing it manually.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]