From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DMARC_QUAR,FREEMAIL_FROM, MAILING_LIST_MULTI autolearn=no autolearn_force=no version=4.0.0 Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.86]) by chiba.3jane.net (Postfix) with ESMTP id 9A1A3ABDA3 for ; Fri, 5 Jul 2002 17:23:53 -0500 (CDT) Received: from smtp-relay02.mac.com (smtp-relay02-en1 [10.13.10.225]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g65MNn8J001877 for ; Fri, 5 Jul 2002 15:23:49 -0700 (PDT) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtp-relay02.mac.com (8.12.1/8.12.1/1.0) with ESMTP id g65MNirE004936 for ; Fri, 5 Jul 2002 15:23:44 -0700 (PDT) Received: from silver.perimeter ([64.34.192.49]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id GYSRJJ00.J4M for ; Fri, 5 Jul 2002 15:23:43 -0700 From: Garry Roseman To: Gentoo-Dev Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 05 Jul 2002 17:23:42 -0500 Message-Id: <1025907823.5550.61.camel@silver.perimeter> Mime-Version: 1.0 Subject: [gentoo-dev] Stow it in the warehouse Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: ff3ea281-e00b-4ebc-9122-42ed784ee483 X-Archives-Hash: 73444c8975eb7d01bd8fb3d1e22feec6 On Fri, 2002-07-05 at 11:33, Wout Mertens wrote: > Hey there, > > I agree, stow is cool and at work we use it to maintain our 12GB > /usr/local tree that is exported over nfs to our workstations. > Some drawbacks, however: > > - You have a slight speed loss because of the symlinking adding > extra lookups. Luckily, Linux has very good caching :) > - Some packages hate it when you symlink stuff; e.g. sudo needs its > sudoers file to be a regular file. Granted, this is a configuration file > and as such may not need to be symlinked in a general gentoo context, so > this could be solved by just creating a regular file in the > pkg_postinst. > - stow -R can grind your server to a screeching halt if you have many > files. I'm sure this is solveable by rewriting the code a little, and I > don't know if recent versions have trouble with it since we don't try it > anymore ;) > - You have a lot of symlinks in your /usr, which makes ls -l a bit less > attractive to look at. Of course, there's still ls -lL ;-) > > I've been considering nagging to drobbins about changing Portage so that > merging actually means > [build the image somewhere where it will remain and install by symlinking] That would be a nice option. Portage developers already do all of the hard work that we stowers often face in assuring that a package will install into a tree outside of its target location. For example, it would be nice if I could emerge a package to a "warehouse" such as /usr/local/stow and just build the package in / (instead of /var/tmp/portage/
//image). Symlinking should be left for a separate manual step. One advantage of emerging into a warehouse is that it becomes possible to define software build environments that are different for different users or for different projects. This is done with Stow by stowing to a special target directory, often a home directory. For example, a user who wants to do development with GCC-3.1 could cd ; stow -t ~/ gcc-3.1 etc. and assuming that his PATH includes ~/bin and the loader is configured to search his $HOME/lib for libraries, etc., then that user can proceed to use gcc 3.1 without interfering with the gcc that is used for normal software installation on the system. I have seen some discussion of using stow for creating and archiving entire project-specific build environments, but I haven't tried it yet. It seems like a good match for portage. > This would have the advantage that you can always revert to a certain > version of a package with certainty, since no files are removed from the > previous package. And you see where a file comes from really quickly by > looking at the symlink, which is very useful. It becomes possible, maybe even easy (so far I find it easy on my 700 MB /usr/local), to revert to the previous release or to jump back and forth between package versions. As I suggested above, it also may become possible to define, track, and archive the entire build environment for software development projects. That is essential for me --- it must be possible to recreate the environment that produced software that I have running in field installations, potentially a different version for each installation. > > And actually, I think it would be possible to let portage optionally have > that feature, because the only thing it changes is where the files are > installed and what merge and unmerge do. All the rest would stay the > same. That way, people who want it can turn it on and the rest aren't > bothered. > > Thoughts? I think there's potential for using portage to build into a warehouse and use stow to withdraw custom environments from the warehouse. But we need experience doing it --- does anyone know how to force emerge to install into a warehouse as I have described it? It appears to me that all we can do right now with portage is to define BUILD_PREFIX to point to the warehouse and portage would put the image into a subfolder but it would create an "image" sub-subfolder -- that's not what we want. The "image" subfolder is superfluous. We would also want emerge to track this package version separately from those installed into /. If an update is released for a warehoused package then let emerge -u world just install the updated version alongside it in the warehouse and let me know that it is available. Updating a warehoused package would not automatically put the new version on the path for execution. Right now using portage to install packages into the local warehouse requires use of "ebuild .ebuild install" followed by "mv /* /" and there is no automatic updating of packages warehoused that way. Given a black-and-white choice between an elaborated system of dependency tracking and file tracking via a database, and a simple warehouse of available versions that can be quickly symlinked into an environment (and allowing user and project-specific environments) --- but with no "query" tool other than "ls" --- I'd take the warehouse and dump the database! But maybe it's not a black and white choice? -- Fuper, Memphis, LPIC-1