[gentoo-user] Delayed update semantics

[gentoo-user] Delayed update semantics

[James]

Hello,

Context: Stable Systems with a few newer packages
(unmasked) in portage.

Some of the recent discussion threads bounce around the issue
of solutions being completed a few days after new packages are release.
Hey, it's Gentoo, we're all keenly aware of this. No problem.
But, from time to time, I get really distracted from Gentoo
with other engineering, social and financial issues, as most on this
list (humanoids refer to this as "having a life") ymmv.


So, being the lazy, aging admin/hack/engineer that I am,
every time I try another distro, it just does not work for
my needs, so like it or not, I'm stuck with Gentoo.....
(dont get me wrong, I love Gentoo, just sometimes
I neglect that (gentoo admin) part of my life for sporadic periods).


So, my latest ideas is to "sync up" and then wait one week
before acutally installing those new packages. This would
allow the fodder that the good folks on this list catch,
bitch about (um, I mean file bug reports) and fix, to 
occur first; then I can complete the package update
cautiously avoiding an "emerge sync".


But when you "emerge sync" if to do the updates immediately, they'll be
the latest packages. If I do a "emerge sync" and wait
7 days to begin updating the packages, I'll be delayed
by one week, and have a one week  of buffered fixes for added
problem filtering. But those fixes might not be available
without a fresh "emerge sync"?


When time permits I CAN CHOOSE to "emerge sync" and then immediately
update the packages and parse through the issues mostly. Call
this the stable-stable approach to gentoo updates.

Does anyone see any problems or a better way to stay one-week-delayed ?

I'm increasingly managing more Gentoo systems, particularly embedded
and server based gentoo systems and that is the source that compounds these
time-sink-issues for me.  Maybe some external-integrated management approach
such as CFengine is my answer?

Your comments and thoughts are most welcome.


James

Re: [gentoo-user] Delayed update semantics

[Alan McKinnon]

On 14/02/2013 21:26, James wrote:
> Hello,
> 
> Context: Stable Systems with a few newer packages
> (unmasked) in portage.
> 
> Some of the recent discussion threads bounce around the issue
> of solutions being completed a few days after new packages are release.
> Hey, it's Gentoo, we're all keenly aware of this. No problem.
> But, from time to time, I get really distracted from Gentoo
> with other engineering, social and financial issues, as most on this
> list (humanoids refer to this as "having a life") ymmv.
> 
> 
> So, being the lazy, aging admin/hack/engineer that I am,
> every time I try another distro, it just does not work for
> my needs, so like it or not, I'm stuck with Gentoo.....
> (dont get me wrong, I love Gentoo, just sometimes
> I neglect that (gentoo admin) part of my life for sporadic periods).
> 
> 
> So, my latest ideas is to "sync up" and then wait one week
> before acutally installing those new packages. This would
> allow the fodder that the good folks on this list catch,
> bitch about (um, I mean file bug reports) and fix, to 
> occur first; then I can complete the package update
> cautiously avoiding an "emerge sync".


This is the one that will give you what you want

> But when you "emerge sync" if to do the updates immediately, they'll be
> the latest packages. 

So don't do that

> If I do a "emerge sync" and wait
> 7 days to begin updating the packages, I'll be delayed
> by one week, and have a one week  of buffered fixes for added
> problem filtering. But those fixes might not be available
> without a fresh "emerge sync"?

If you see everyone else whinging about X and you want X, then sync and
emerge right now. You will potentially get a bunch of current stuff that
breaks stuff, and you will have to deal with that on the rare occassion
it happens


> When time permits I CAN CHOOSE to "emerge sync" and then immediately
> update the packages and parse through the issues mostly. Call
> this the stable-stable approach to gentoo updates.
> 
> Does anyone see any problems or a better way to stay one-week-delayed ?

no, there is no better way.

gentoo does not support partial syncs so you can't be picky


> 
> I'm increasingly managing more Gentoo systems, particularly embedded
> and server based gentoo systems and that is the source that compounds these
> time-sink-issues for me.  Maybe some external-integrated management approach
> such as CFengine is my answer?
> 
> Your comments and thoughts are most welcome.
> 
> 
> James
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Delayed update semantics

[Daniel Frey]

On 02/14/2013 11:26 AM, James wrote:
> Hello,
> 
> Context: Stable Systems with a few newer packages
> (unmasked) in portage.
> 
--snip--
> 
> So, my latest ideas is to "sync up" and then wait one week
> before acutally installing those new packages. This would
> allow the fodder that the good folks on this list catch,
> bitch about (um, I mean file bug reports) and fix, to 
> occur first; then I can complete the package update
> cautiously avoiding an "emerge sync".

I suppose you could set up a weekly cron job (say on a Saturday) to do
something like:

emerge -fuDN world > proposed_change.txt

Then a few days later (say Wednesday?) email that file to yourself so
you know what changes are being proposed. This will give you a
"snapshot" in email of changes week-to-week. I've done this before and
you'll just get output like this (in this case, I did mythtv only, not
world):

These are the packages that would be merged, in order:

Calculating dependencies  .... done!
[ebuild   R   ~] media-tv/mythtv-0.26.0_p20130121


You can then manually apply the updates.

> 
> But when you "emerge sync" if to do the updates immediately, they'll be
> the latest packages. If I do a "emerge sync" and wait
> 7 days to begin updating the packages, I'll be delayed
> by one week, and have a one week  of buffered fixes for added
> problem filtering. But those fixes might not be available
> without a fresh "emerge sync"?

Yep, but if you set up an email above, you'll know which versions are
proposed and you can even search for problems beforehand. Additionally,
because you now have an email copy of it, you could probably set up
grep/awk/head/tail/etc to strip out everything but the package prefixed
with an '=' so it only pulls those packages. This way even if it syncs
again on its cron, you'll still have a list of packages, but this
doesn't help if the sync removes existing packages from portage (which
can happen.)

> 
> 
> When time permits I CAN CHOOSE to "emerge sync" and then immediately
> update the packages and parse through the issues mostly. Call
> this the stable-stable approach to gentoo updates.

Yep, but it's still work. Especially if you forgot one week and have to
update the packages manually.

> I'm increasingly managing more Gentoo systems, particularly embedded
> and server based gentoo systems and that is the source that compounds these
> time-sink-issues for me.  Maybe some external-integrated management approach
> such as CFengine is my answer?

CFEngine? I didn't even know what that was until now. I've usually just
used tools readily available on most installs that didn't require extra
software.

Dan

[gentoo-user] Re: Delayed update semantics

[Nuno Silva]

On 2013-02-14, James wrote:

> So, my latest ideas is to "sync up" and then wait one week
> before acutally installing those new packages. This would
> allow the fodder that the good folks on this list catch,
> bitch about (um, I mean file bug reports) and fix, to 
> occur first; then I can complete the package update
> cautiously avoiding an "emerge sync".

The fun thing is that this is supposed to be why we do have unstable
keywords. Some of the breakage which happened and hit the stable tree
with no timely news item was actually discussed for some time before in
the -devel list. You may want to follow that list too.

That "sync up" you talk about is effectively equivalent to having ~amd64
for amd64.

> But when you "emerge sync" if to do the updates immediately, they'll be
> the latest packages. If I do a "emerge sync" and wait
> 7 days to begin updating the packages, I'll be delayed
> by one week, and have a one week  of buffered fixes for added
> problem filtering. But those fixes might not be available
> without a fresh "emerge sync"?
>
>
> When time permits I CAN CHOOSE to "emerge sync" and then immediately
> update the packages and parse through the issues mostly. Call
> this the stable-stable approach to gentoo updates.
>
> Does anyone see any problems or a better way to stay one-week-delayed ?

Packages with problems simply shouldn't hit stable. I'd rather just do
--sync and perform world upgrades, and I would just keep an eye on the
triggered updates, in order to spot any potentially problematic package
(like c++-based libraries).

> I'm increasingly managing more Gentoo systems, particularly embedded
> and server based gentoo systems and that is the source that compounds these
> time-sink-issues for me.  Maybe some external-integrated management approach
> such as CFengine is my answer?
>
> Your comments and thoughts are most welcome.

Your problem does not seem to be emerge --sync, but that you run
commands that cause existing upgrades to be applied on a system-wide
basis.

If there is a fix you need/want, re-emerge that specific package, and
let the others wait. Only the strictly needed dependencies should be
pulled this way. You're not forced to use "-DuN world" or even "-DuN"
every time you want to upgrade something.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Delayed update semantics

[Yuri K. Shatroff]

On 15.02.2013 00:58, Daniel Frey wrote:
> On 02/14/2013 11:26 AM, James wrote:
>> Hello,
>>
>> Context: Stable Systems with a few newer packages
>> (unmasked) in portage.
>>
> --snip--
>>
>> So, my latest ideas is to "sync up" and then wait one week
>> before acutally installing those new packages. This would
>> allow the fodder that the good folks on this list catch,
>> bitch about (um, I mean file bug reports) and fix, to
>> occur first; then I can complete the package update
>> cautiously avoiding an "emerge sync".
>
> I suppose you could set up a weekly cron job (say on a Saturday) to do
> something like:
>
> emerge -fuDN world > proposed_change.txt

AFAICT, if you do not really do an emerge --sync, this command will 
repeatedly show nothing.

 > Then a few days later (say Wednesday?) email that file to yourself so
 > you know what changes are being proposed.

You surely know, there is a great toolset, eix, which has eix-sync 
command that does emerge --sync and shows all updated ebuilds.
But anyway, to update a package, you'll have to sync.

>> When time permits I CAN CHOOSE to "emerge sync" and then immediately
>> update the packages and parse through the issues mostly. Call
>> this the stable-stable approach to gentoo updates.

IMHO that is not a solution: rather, a solution is not to update world 
but pick single packages to update. Most software does not *require* an 
update, unless there are security/stability issues. So doing a world 
update to track such issues is kinda hunting sparrows with a mortar.
And practical experience has it that "it works, and don't touch it". 
Pretty often some unnecessary update causes an unnecessary mess, even if 
the dev guys put it as stable.

A delay after emerge --sync is pretty useless because you end up with a 
(week-)old portage tree, so to fix any possible bugs found that week, 
you'd do another sync so... you see.

For the purpose of stability, I don't see an alternative to doing emerge 
--sync but singling out packages to update rather than updating world.

In the real world, there's no 100% secure way to be 100% secure, you 
know. You just choose the path you deem more suitable based on risk/work 
and efficiency/work relations.



-- 
Best wishes,
Yuri K. Shatroff

Re: [gentoo-user] Delayed update semantics

[Tanstaafl]

On 2013-02-14 2:26 PM, James <wireless@tampabay.rr.com> wrote:
> So, my latest ideas is to "sync up" and then wait one week
> before acutally installing those new packages. This would
> allow the fodder that the good folks on this list catch,
> bitch about (um, I mean file bug reports) and fix, to
> occur first; then I can complete the package update
> cautiously avoiding an "emerge sync".

I do something similar, but on a rolling basis...

1. Sync daily, keeping track of what updates appear *and when*

2. Once a package that wants to be updated has been in the list for
    at least 3 days, I update it/them, although I will usually wait
    a little longer (week or two) for some things, like things that
    are critical to booting (like grub, udev, etc)

3. Rinse, repeat

I started doing it this way ever since I got bit by the mailman minor 
update that broke things horribly (moved where all of its files were 
located without any warning, news item, or anything - ugh), and it has 
served me well.

I do this manually, but I only have a couple of systems to manage. 
Obviously if you manage multiple systems, the more systems you manage, 
the more unwieldy doing this manually becomes, so scripting the process 
(or at least part of it) would become necessary at some point.

[gentoo-user] Re: Delayed update semantics

[James]

Tanstaafl <tanstaafl <at> libertytrek.org> writes:


> I do something similar, but on a rolling basis...

Thanks to everyone for input.

I'm going to have to think about this some more
and what existing packages/scripts to integrate
into what I need....

Thanks to everyone for the comments and ideas.


James