delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2020/12/19/01:39:35

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]" <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: <f5ab1b6f-dbf3-4be3-a43f-eb74b32b7a51 AT fastmail DOT com>
<ae7dca70-44c9-d905-498e-e7768a279af7 AT epilitimus DOT com>
<83d2a9f4-89a5-cf7b-4c94-738e14327057 AT fastmail DOT com>
MIME-Version: 1.0
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

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019