Re: [gentoo-user] anti-portage wreckage?

[Boyd Stephen Smith Jr.]

On Monday 25 December 2006 22:41, "Mike Myers" <fluffymikey@×××××.com> 
wrote about 'Re: [gentoo-user] anti-portage wreckage?':
> On 12/25/06, Boyd Stephen Smith Jr. <bss03@××××××××××.net> wrote:
> > On Monday 25 December 2006 14:09, "Mike Myers" <fluffymikey@×××××.com>
> > wrote about 'Re: [gentoo-user] anti-portage wreckage?':
> > > Anyways, all I'm essentially asking for is a way to separate minor
> > > updates from major updates.
> > With some of the advanced atom operators (particularly '*' and '~'),
> > you should be able to specify exactly what level of masking you want.
> > You could also make your own profile that does "cap" packges at a
> > certain version and have it's parent be an established profile,
> > although I'm not sure that bit of portage hackery is supported.
> I know these things could be done, but I don't really think it's worth
> it. The problem is that these kinds of solutions don't scale very well..
> they don't really scale at all really.  If I have to reinstall for
> whatever reason, then I have to redo all this hackery, as you put it,
> heh.

You can easily replicate the contents of a profile or /etc/portage across 
multiple system with something like rsync; you should also have the 
entirety of /etc backed up in case you need to reinstall -- it holds all 
your services' configurations anyway.

> In any case, this is still a bit of a reactive approach, since I
> have to be aware that there may be a problem with a particular update
> before I know to mask it.

No, you can mask packages before they exist, so you can choose to be 
reactive or active.  For example, to prevent emerge -u from updating a 
package add >category/package-version to package.mask, even if there's not 
an upgrade waiting.  Again, proper use of the package atoms should enable 
you to only enable -rX upgrades (which are ebuild changes; not upstream) 
or -rX and last version number upgrades (which should be ABI compatible if 
upstream is sane) etc. etc.

It's certainly possible to build a system of scripts around emerge to do 
all this masking for you, and the PYE (pick-your-emerge) script that is 
(used to be?) popular on the forums could be a good starting point.

One thing that would make it a *lot* easier is if /var/lib/portage/world 
supported the full atom syntax instead of just atom bases and doing 
something like 'emerge "<category/mysql-5"' would add the atom from the 
command line to the world file instead of the atom base.  [Then, most of 
the time, you wouldn't have to mask anything at all.]

> I really like the idea of the tree version
> thing though.  I'll see if there's anything I can do to support that.

Yeah, I certainly would *mind* tree versioning.  Although... I'm not quite 
sure how it would mesh with the accepted ~ARCH keywording.  I see how they 
could work together, but they also seem to overlap uncomfortably.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh