Instead of -rY-localX, I do -rX0Y the following in my local overlays. This gets the same effect and maintains both version numbers. And if you are worried about a revision number exceeding 99, then just do -rX00Y. This works without requiring code change to portage.
[EMAIL PROTECTED] wrote: [Fri Oct 20 2006, 07:05:22PM EDT] > Hello all, > > In designing an enterprise infrastructure around Gentoo at my place of > employment, I have discovered a feature that would improve Gentoo's > usefulness greatly in this field. > > I'm writing to ask for your opinion on a change to sys-apps/portage that > would allow users to maintain local revisions of ebuilds, such as > "net-www/apache-2.0.58-r2-local1". This would require a modification to > the ebuild version specifications and a patch to two portage source > files which you can review here: > > http://dev.gentoo.org/~malverian/portage_local_version.patch > > (Please don't complain about the code quality, I cleaned up areas where > it was desparately needed such as the string.atof() areas, but for the > sake of code coherence, I tried to use the same methodology used elsewhere > in the code as much as possible, such as unqualified except statements :P) > > There are a number of scenarios where such a feature is useful, most of > which revolve around the need for a local version bump: > > 1) You have machines using apache-2.0.58-r2 with an unpatched security > hole which you would like to immediately patch locally until a fix is > committed to the portage tree. > > 2) You are using binary packages and need to simulate a version bump to > force re-installation of a binary package with modified USE flags. > > 3) You are using binary packages and need to simulate a version bump to > force re-installation of binary packages that were rebuilt during > revdep-rebuild > > In all of the above cases, one could simply bump the package up one > revision by creating an ebuild in an overlay for apache-2.0.58-r3. > However, using this solution will result in apache not being upgraded > when apache-2.0.58-r3 is actually committed to the portage tree unless > you perpetuate this bad habit ad nauseum. > > To give a better explanation of #3, consider the following scenario: > > - You have 60 servers with mysql-4.0.28 and php-5.1.6-r2 > - You want to upgrade to mysql-5.0.30 and continue to use php-5.1.6-r2 > - You use binary packages which are built on a staging machine > - Your servers know to upgrade via a "pull" method with the help of > cfengine which tells each server what packages SHOULD be installed on > it. This also makes it very easy later to build another copy of a > machine in the case of hardware failure by using the same description > files (cfengine config programs) > > To accomplish the above in an enterprise environment, you would need to > perform the following steps: > > 1) Install mysql-5.0.30 on the staging machine and build binary packages > > 2) Perform a revdep-rebuild on all packages using libmysql client > libraries, building new binary packages for each of them > > 3) Tell your other 60 servers that it is time to upgrade mysql (and in > this case, reinstall php) > > Assuming you have a description file such as the following: > > __CUT__ > > webserver_packages = > ( > dev-db/mysql-4.0.28 > dev-lang/php-5.1.6-r2 > ) > > ... > > __CUT__ > > It is obvious what change must be made to install the new version of > MySQL, but how do you update PHP without bumping the version of PHP? You > would need some extra metadata to tell the servers if they are upgrading > from mysql-4.0.28 to mysql-5.0.30 that they should reinstall PHP. This is > fine for a few packages, but it can quickly become a maintanence > nightmare. > > Having local revision numbers solves this problem very simply, and > provides quite a bit of flexibility as a side-effect. > > > NOTES: > > - The "-local#" revisions MUST NOT be used in the main portage tree. It > is something that system administrators would have exclusively for their > own purposes such as those described above. This SHOULD probably be > enforced by repoman in addition to policy changes. > > - The new (completely backward compatible) version priority order would be: > > apache-2.0.58 > apache-2.0.58-r1 > apache-2.0.58-r2 > apache-2.0.58-r2-local1 > apache-2.0.58-r2-local2 > apache-2.0.58-r3 > apache-2.0.59 > > -- > gentoo-dev@gentoo.org mailing list > Joel Martin (kanaka) Open Source no BILL . no GATES Costs nothing . Open to all
pgp7wmNuCLafO.pgp
Description: PGP signature
