From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8480 invoked by uid 1002); 11 Nov 2003 21:20:00 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 16598 invoked from network); 11 Nov 2003 21:19:59 -0000 Message-ID: <3FB15269.7040000@sentuny.com.au> Date: Wed, 12 Nov 2003 08:19:37 +1100 From: Ron OHara User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sami K M Naatanen Cc: gentoo-dev@gentoo.org References: <3FAEFF54.8010804@sentuny.com.au> <200311111718.45352.sami.naatanen@cs.helsinki.fi> In-Reply-To: <200311111718.45352.sami.naatanen@cs.helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-Wally-MailScanner: Found to be clean Subject: Re: [gentoo-dev] Maintaining production systems - and losing ebuilds X-Archives-Salt: 3a8445c1-4675-44c2-97d7-fcd825c7e4b6 X-Archives-Hash: 14cf9c3358ab7187670ccabe209ace2e In this case I dont want to make revdep-renuild ignore the version - I just need it to recompile the version of everything that has been installed. In a production environment, I cant just 'upgrade' many versions of software without regression testing of the applications in that environment. I need to be able to apply security fixes (like the openssl library) and still have the installed set of software work. One change at a time is crucial for production systems stability. Ron Sami K M Naatanen wrote: >On Monday 10 November 2003 05:00, Ron OHara wrote: > >revdep-rebuild --help and you will see that you can set the revdep-rebuild to >ignore the version. You might have problems getting the files, because wget >depends from openssl (if you have ssl in your USE). But do emerge -fp wget >and you get a bunch of URI's download every file and dump them in the >/PORTDIR/distfiles/ emerge wget. > >revdep-rebuild with the version ignoring option. or you can >first add -- -p to see what emerge would rebuild. > >If your portage version is too old (ie your version of revdep-rebuild doesn't >support options) then do emerge -fp portage and download all of those files. > >You also could try to add link 0.9.6 to the 0.9.7 version of the ssl lib. This >should work. Based on the fact, that it seems that the new openssl ebuild >misses the link creation according to some people. > > > >>Hi, >> >>I want to raise an issue resulting from my experience so far in using >>Gentoo as the basis of production systems. Some may ask why? - but >>basically 'portage' seems to offer the very best framework for ongoing >>maintenance/admin of systems, though it's not perfect in that role. >> >>In essence, the continuous, easy upgrade capability of portage is great >>for a development system and should be an excellent mechanism for >>critical security (and other) upgrades in a production environment (and >>it is). >>The problems arise because of the continuous easy upgrades!! - the main >>benefit is also the main problem. >> >>I have just hit a real life hassle with a security upgrade. The history >>of it goes like this: >> >>[background] >>The example system in trouble is an old P233, and used to be on the end >>of a dialup link (it's now ADSL). >>Gentoo has been installed for about 10 months and the last time it was >>brought completely up to date was about 6 months ago (emerge rsync && >>emerge -u world) >>[/background] >> >> >>[creating a problem] >> >>As you have guessed, I've just had some system problems - partly of my >>own creation, but partly because of how Gentoo operates. >> >>My real problem came from doing 'emerge rsync', and then just >>(selectively) doing 'emerge -u openssl' >> >>This installed 'openssl-0.9.7' and removed 'openssl-0.9.6' - >>unfortunately lots of stuff on the system was compiled and linked >>against 'openssl-0.9.6' and they promptly broke. IE. Serious outage on a >>production system. >> >>There is a script designed to fix this called 'revdep-rebuild' which >>scans all the installed binaries for broken dependencies and then >>recompiles them which should make them link against the nice new >>'openssl-0.9.7' >> >>except!!! - revdep-rebuild carefully tries to recompile the exact >>versions of software you have installed (good idea) - but the Gentoo >>central repository has since deleted some of the build scripts for these >>older versions and when I did the 'emerge rsync', the scripts were also >>removed from my system. So I ended up where I am now - I have to go >>through and do 'emerge -u world' and then 'revdep-rebuild' to get it all >>working... not nice when there are nearly 200 packages to >>download/recompile on an old P233 >> >>[/creating a problem] >> >> >> >> >>As you can see, I was intending to leave the installed set of packages >>(and versions) alone. For this machine (and any production system), I >>dont want to install each and every little patch as it comes along. The >>machine is 'stable' - so I only want to apply upgrades on a very >>selective, controlled, manual basis - but still use portage for the >>package management. >>This is a very common tactic for 'production' machines, where you want >>the minimum number of changes to reduce your risks of outage. >> >>The trap is that 'emerge rsync' removes old .ebuilds that your installed >>machine may need if revdep-rebuild is to be able to recovery things >>after a critical library is rebuilt. >>In the way portage works, the only time it is safe for 'emerge rsync' to >>delete ebuilds, is immediately after successfully doing 'emerge -u world'. >> >> >>Is there a way to suppress the 'delete' part of rsync? Maybe a setting >>in /etc/make.conf ? >> >>That way, even though Gentoo may have removed the relevant (old) ebuild >>I want, the target machine would have it's local portage version for >>future recompiles.... I can afford the disk space!!! >> >> >> >> >>Regards >>Ron OHara >>PS: This is not a 'casual' problem for me - I've convinced a client to >>use Gentoo for the basis of their deployments and the plan is supposed >>to be for around 900 sites!! - catering for production software support >>for the next decade is very relevant to things in this scenario. >> >> > > > -- gentoo-dev@gentoo.org mailing list