From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F16EF1381F3 for ; Wed, 29 May 2013 02:08:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9B4F0E0B03; Wed, 29 May 2013 02:08:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2C750E0B03 for ; Wed, 29 May 2013 02:08:44 +0000 (UTC) Received: from [192.168.1.210] (S010600222de111ff.vc.shawcable.net [96.49.5.156]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dolsen) by smtp.gentoo.org (Postfix) with ESMTPSA id 21F5B33BE5C for ; Wed, 29 May 2013 02:08:43 +0000 (UTC) Message-ID: <1369793318.3446.100.camel@big_daddy.dol-sen.ca> Subject: [gentoo-catalyst] PKGCACHE_PATH and os.makedirs() usage From: Brian Dolbec To: "gentoo-catalyst@lists.gentoo.org" Date: Tue, 28 May 2013 19:08:38 -0700 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@lists.gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Archives-Salt: 58d1cd52-ffc0-4d64-ad18-2df4cecc42c6 X-Archives-Hash: b8b8b26d951b0ca508dd5533f577092c While investigating why the stage1 build was not creating or using binpkgs as expected. I discovered that the PKGCACHE-PATH dir was not being checked for existence nor being created if it didn't. I did however discover that it was indeed checked and/or created in livecd_stage2.py. It should be done in the StageBase class (my rewrite) where it it set upon the class's initialization. This will centralize the operation to one common location. This portion is something easily done in the current master and probably desirable for the next release. Further investigation of the use of os.makedirs() reveals that none of it's frequent use does any error checking or exception escaping. I propose to move this common code to either a utility function or possibly a FileOps class that the main classes can then subclass or create an instance of. I need to investigate what method will be best. That way, exceptions can be controlled for the type of failure desired. As well as proper shutdown procedures to run for a failure. If it is moved into a class, I may also move the pack/unpack operations into it, removing some of the complexity from the currently overloaded base stage classes. They are after all file operations. Again, something to be determined. What say everyone?