<snip>
> So I guess this is amended to portage just doing its best and telling 
> me when it can't do it. That way I'm the sysadmin making the decision 
> what to do with a changed machine - eg, I could decided to update the 
> whole system and re-QA it.
</snip>

Very good discussion. I think this would be an excellent approach as
well. If I am understanding correctly, the process would be as follows:

1. emerge sync.
2. run script against portage to protect stable packages
3. update normally

This would have many major benefits. Especially if major package version
changes for stable packages can be done on a quarterly/semi-annual
basis. With only security patches being applied in the interim.

It would be very nice to have the QA script recognize and
respect /etc/portage configurations. Or have its own configuration.
Possibly for packages that one intentionally wants to push outside of
the stable tree. Something similar to package.keywords, only not moving
to unmasked or ARCH, but rather just to current package marked stable in
the main tree.

It would also be nice if one had to manually change to a new stable tree
via make.conf. This way, an admin knows exactly when they will be making
major version changes. In this scenario, if I make the change in
make.conf, emerge sync and re-QA the tree against the new profile, I can
run an emerge -uDp world against my current setup and take a look at
what I'm getting myself into. I can then make decisions on what can or
will break and possibly choose to roll back to the previous snapshot
until I have a day available to update and test correctly.

This would also be excellent for regression testing on a test server
with the new stable snapshot before switching anything, but still be
confident that your production servers are running with updated security
patches applied.

The only area I see potential problems is with python apps. (Correct me
if I'm wrong) Portage depends on stable and fairly specific versions of
python. Some python apps may be pushed beyond where they should, or held
back based on the portage version of python. I don't know if python is
slottable or not yet, but if it isn't, this may be something to bring
up, since I think this is and has been a problem. The way many packages
work around this is to include their own copy of python. Not something I
really like, but appears to be the solution at present.

Wendall

Reply via email to