On Monday 25 December 2006 22:41, "Mike Myers" <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-user] anti-portage wreckage?': > On 12/25/06, Boyd Stephen Smith Jr. <[EMAIL PROTECTED]> wrote: > > On Monday 25 December 2006 14:09, "Mike Myers" <[EMAIL PROTECTED]> > > 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
pgpm6xdDY08a5.pgp
Description: PGP signature
