X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <20201219061954.15874.qmail@stuge.se> Date: Sat, 19 Dec 2020 06:19:54 +0000 From: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] Problem with Guile 2.2.4 dependency for gEDA 1.10.1. References: <83d2a9f4-89a5-cf7b-4c94-738e14327057 AT fastmail DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83d2a9f4-89a5-cf7b-4c94-738e14327057@fastmail.com> Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Girvin Herr (gherrl AT fastmail DOT com) [via geda-user AT delorie DOT com] wrote: > That is what I was afraid of. I have installed "current" Slack packages > in the past with the latest released version with mixed results. It > looks like gEDA is frozen for me at 1.10.0 until the "current" Slack is > released. You don't have to settle for that; it's perfectly possible to install different versions of most packages (in particular all relevant for 1.10.1) to a new directory, where they do not interact with distribution packages. Only a few distributions offer tooling to automate (some of) the process and Slackware is not one of them, so it takes some work, but if you have the time and are curious I highly recommend giving it a go! The alternative to revert that one commit is fewer steps, but may need/yield more development skill. Installing other packages is more work, but needs/yields more system integration/administration skill. So this is my general recipe for installing packages like that. I'd recommend creating a new user when doing this exercise the first time. Everything is done as that user. Nothing needs to be run as root or with sudo, yet the finished result will still be runnable by your existing user. Let's say the user is called builder. Create and log in as the user. The packages will be installed into the directory inst/ under the home directory of the builder user. In order for the build process for later packages to find "earlier" dependencies run this on every login: (automate by adding it e.g. to .profile) export PKG_CONFIG_PATH="${HOME}/inst/lib/pkgconfig" export PATH="${PATH}:${HOME}/inst/bin" Then download source tarballs and unpack in the home dir as needed. Why not start with guile-2.2.4.tar.gz. Unpack it, then run: cd guile-2.2.4 ./configure --prefix=$HOME/inst # so then configure probably complains about some missing dependency. Download # that tarball and unpack in the home directory, cd in, then run the same above # configure command, and then: make install # note! do not use sudo and do not run as root! This installs into the inst/ subdirectory of the builder home dir. Iterate until all dependencies are installed. I guess it'll be some 10 packages, so you'll get good practice. gEDA can also be built this way. As long as packages use pkg-config to find their dependencies (I think all the relevant ones do) and your PKG_CONFIG_PATH environment variable is set correctly this will work very well. Once you're done, back as your normal user, run this: export PATH="/home/builder/inst/bin:${PATH}" ..and then you'll be able to run whatever was built and installed into that inst/ directory as the builder user but from your ordinary user. Since the exercise is completely contained in the new user's home directory (because nothing ever runs using sudo nor as root) you can start over at any time by deleting and re-creating the user or just the home dir. It is not insignificant effort, but it's completely doable and especially if you want to get something done and not stay blocked by someone else, who may have limited time to work on the distribution you use, this is a useful method. It does get annoying as the dependency tree grows however, and at that point it may be worth considering to just consume a more up-to-date distribution and/or its tooling within a chroot - a very different approach to the above. If anyone wants more documentation about what this actually does I think the Linux From Scratch documentation is the best I can suggest. Kind regards //Peter