[Slackbuilds-users] Updates - 20230128.1

[Erich Ritz]

------- Original Message -------
On Monday, January 30th, 2023 at 1:26 AM, B. Watson <urchlay at slackware.uk> wrote:


> 
> 
> 
> 
> 
> Sorry, this got a little more verbose than I intended. I'm writing to
> the whole list, so I might be explaining things you already know. Bear
> with me...
> 
> On Mon, 30 Jan 2023, Duncan Roe wrote:
> 
> > > If it's already been sourced, sure, you might end up with duplicates
> > > in $PATH or such, but that won't cause any harm. And it'll save a lot
> > > of headaches, and make automated mass-rebuilds a lot easier.
> > 
> > Ah well. The thing is, you have to source the profile script in your terminal
> > session: it's no use the SlackBuild or installpkg doing it because the
> > environment of the process running the command is lost on command completion.
> 
> 
> You're right that it's useless for google-go-lang.SlackBuild to source
> its own profile script. I meant, containerd.SlackBuild should source
> it. Then the environment will be set up correctly for the build,
> without the user having to take manual steps to set it up.
> 
> Just put the line "source /etc/profile.d/go.sh" somewhere near the
> top of containerd.SlackBuild, and it no longer depends on the user's
> shell environment.
> 
> If every build that requires google-go-lang contains that line,
> they'll all work right after google-go-lang is installed, no need to
> adjust the terminal's environment.
> 
> A nice side benefit of this is that the script will fail immediately
> if google-go-lang isn't installed.
> 
> Back when qt5 was on SBo, I routinely did this in my own scripts that
> depended on qt5. I do it in a couple of builds that use Java too,
> though those only search for a profile script if JAVA_HOME isn't
> already set, and they have to look for multiple possible profile
> scripts since we have several JDKs to choose from.

Bingo.  Multiple packages that depend on java pick a version to put in REQUIRES but then the README notes that you can optionally use a different version.  If the SlackBuild tries to source the version in REQUIRES it will fail hard.

We should be really careful adding "helpful" automation.  There is always a balance to be struck.  Where does it end?  Should every package do an explicit check for all of its dependencies to give a helpful error message?  How robust should that be to different versions of dependencies?  How many support requests are there that end up being the user didn't install all dependencies?

Note that some tools (e.g. slackrepo) take care to source the appropriate profile scripts automatically during the build.  So for me personally this is a non-issue, which is why I'm arguing against adding complexity to the SlackBuilds themselves.

Erich

> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/