Please provide free language description of what is SBo script

crts · 11-06-2019, 09:44 PM

Quote:

Originally Posted by Richard Cranium

I'm starting to believe that @igadoter is a PhD studying psychology and we are part of some type of experiment.

I have been having the same thoughts for quite some time now, especially with some new members that keep popping up occasionally. Their questions sometimes seem a bit "odd", not in the sense that their english is inadequate but I sometimes get the impression that someone is training some kind of AI. The only purpose of their threads seems to be to determine some kind of "sociological impulse response". Does anyone remember the "Shlomo bot" a few months (or last year?) back? His threads were particularly weird.

PS:
I do not think that @igadoter is a bot.

igadoter · 11-07-2019, 04:20 AM

Quote:

Originally Posted by Didier Spaier

OK. Now, what is the next step? What can we do with this description?

First of all it is needed to provide many description. Next step on such descriptions is to extract things which are common This should allow to create abstract of script. Having abstract one can now go opposite way. Forget about script and focus only on script abstract. Now script is described in abstract language - there is engine which take this description and produces real script. Of course final script doe not have to follow sbo scripts. But it should do the same job. Once package is being created script goes into trash. Abstract description remains.

igadoter · 11-07-2019, 04:25 AM

Quote:

Originally Posted by Richard Cranium

I'm starting to believe that @igadoter is a PhD studying psychology and we are part of some type of experiment.

You know? World of science is so crazy that someone would really take this as idea the subject. Nowadays every human activity can be taken subject of scientific research. Yeah, but I think for some here it is rather me who require psychological treatment.

igadoter · 11-07-2019, 04:29 AM

Quote:

Originally Posted by urbanwks

This is categorically untrue as most if not all are BSD/MIT (a bit nuts to suggest as well, since a quick look at any slackbuild proves otherwise), and the absolute refusal to do something as simple as going to slackbuilds.org and grabbing any random script simply to paste here convinces me (and others I'm sure) that there's no interest in doing anything at all on your own.

These are personal matters. If want to discuss work of a person in presence of that person. Just politely to ask for permission.

Didier Spaier · 11-07-2019, 10:02 AM

Quote:

Originally Posted by igadoter

First of all it is needed to provide many description.

To get started you could just clone the current repository of https://slackbuilds.orgs with this command:

Code:

 git clone https://git.slackbuilds.org/slackbuilds/

As of now, you will get no less that 7770 SlackBuilds:

Code:

didier[/data]$ find slackbuilds -name "*.SlackBuild"|wc -l 
7770

As already stated it is perfectly legit to write a description for each of them, no authorization needed from anyone, so feel free to do it and/or find people willing to do it.

igadoter · 11-07-2019, 01:44 PM

Quote:

Originally Posted by GazL

And here's one of mine, which doesn't follow the SBo template, though its pretty much the same process.

Code:

#!/bin/sh
# Build script for 'cwm'  ( based on build_template 1.5 )

set -e

DATE="$(date +%Y%m%d)"

PRGNAM='cwm'
BUILD="${BUILD:-1}"
TAG="${TAG:-_local}"

case "${ARCH:=$(uname -m)}" in
      i686)  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
             LIBDIRSUFFIX=""
             ;;
      i586)  SLKCFLAGS="-O2 -march=i586 -mtune=i686"
             LIBDIRSUFFIX=""
             ;;
      arm*)  ARCH="arm"
             SLKCFLAGS=""
             LIBDIRSUFFIX=""
             ;;
    x86_64)  SLKCFLAGS="-O2"
             LIBDIRSUFFIX="64"
             ;;
      s390)  SLKCFLAGS=""
             LIBDIRSUFFIX=""
             ;;
         *)  SLKCFLAGS=""
             LIBDIRSUFFIX=""
             ;;
esac

CWD="$(pwd)"
PKGTMP="$(mktemp -t -d "pkg-$PRGNAM.XXXXXX")"
SRCTMP="$(mktemp -t -d "src-$PRGNAM.XXXXXX")"

########################################################################

# Unpack:

SRCDIR="/usr/src/$PRGNAM"

if [ -d "$SRCDIR/.git" ]; then
  cd "$SRCDIR"
  VERSION=$( git describe --abbrev=0 )
  mkdir "$SRCTMP/$PRGNAM-$VERSION"
  cp -R * "$SRCTMP/$PRGNAM-$VERSION/"
else 
  TARBALL="$(find "$CWD" -maxdepth 1 -name "${PRGNAM}*.tar.*" | head -n 1)"
  VERSION="${TARBALL##*/${PRGNAM}-}"
  VERSION="${VERSION%.tar.*}"
  cd "$SRCTMP" && tar xvf "$TARBALL"
fi

cd "$SRCTMP/$PRGNAM-$VERSION"

# Build:

CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
make PREFIX=/usr MANPREFIX=/usr/man DESTDIR="$PKGTMP" install

# Support files:
cp $CWD/startcwm "$PKGTMP/usr/bin/startcwm"
chmod 755 "$PKGTMP/usr/bin/startcwm"
mkdir -p "$PKGTMP/etc/X11/xinit/"
cp $CWD/xinitrc.cwm "$PKGTMP/etc/X11/xinit/xinitrc.cwm"

# Docs:
mkdir -p "$PKGTMP/usr/doc/$PRGNAM-$VERSION"
cp -a -t "$PKGTMP/usr/doc/$PRGNAM-$VERSION" \
          README 
cp $CWD/cwmrc.sample "$PKGTMP/usr/doc/$PRGNAM-$VERSION"

########################################################################
# Packaging:

OUTPUT="${OUTPUT:-/tmp}"
PKGFILE="$OUTPUT/$PRGNAM-${VERSION//-/_}-$ARCH-$BUILD$TAG.${PKGTYPE:-txz}"

mkdir -p "$PKGTMP/install"
cat "$CWD/slack-desc" > "$PKGTMP/install/slack-desc"

if [ -f "$CWD/doinst.sh" ]; then 
  cat "$CWD/doinst.sh" > "$PKGTMP/install/doinst.sh"
fi

cd "$PKGTMP" && /usr/local/bin/buildpkg "$PKGFILE"

########################################################################

Pretty self explanatory, other than 'buildpkg'.

This should be enough

Code:

-> class Script
-> cwm = Script("cwm")
-> cwm.makescript("local")

montagdude · 11-07-2019, 01:47 PM

Quote:

Originally Posted by igadoter

This should be enough

Code:

-> class Script
-> cwm = Script("cwm")
-> cwm.makescript("local")

Well there you go, you've figured it out. Don't forget to mark this thread solved.

igadoter · 11-07-2019, 01:59 PM

Quote:

Originally Posted by montagdude

Well there you go, you've figured it out. Don't forget to mark this thread solved.

Yeah, I figured out that there is bunch of over authoritative people here. They always know better. But you know? Every forum (at least in Linux world) is plagued by the same disease. I was in so many absurd and nonsensical situation - you would just do not believe me. The reason was always the same: bunch of ghouls with sharp claws who ready to tear you to pieces. Another story. When the first car appeared people argued against it because cart pulled by pair of horses is much faster. If people rely only on what they know - then every thing they do is reincarnation of things already being done. There was a time Linux was adventure - now is just - just you know - boring.

montagdude · 11-07-2019, 02:17 PM

Quote:

Originally Posted by igadoter

Yeah, I figured out that there is bunch of over authoritative people here. They always know better. But you know? Every forum (at least in Linux world) is plagued by the same disease. I was in so many absurd and nonsensical situation - you would just do not believe me. The reason was always the same: bunch of ghouls with sharp claws who ready to tear you to pieces. Another story. When the first car appeared people argued against it because cart pulled by pair of horses is much faster. If people rely only on what they know - then every thing they do is reincarnation of things already being done. There was a time Linux was adventure - now is just - just you know - boring.

By all means, present something, and then we can decide whether we like it or not. I can't even understand where you are trying to go with this thread. When people answer your questions, you reply with nonsense like in post #96 above. Do tell, when you run that code, what happens? Absolutely nothing. I don't even know why I'm replying at this point. I guess because I'm annoyed that you keep jerking people around who are actually trying to be helpful.

If you were really serious about this idea, you would get something basic working and then present it for testing. I guarantee you that if you did that, the response would be overwhelmingly positive. But as far as I can judge from your posts in this thread, you are not actually interested in doing any work at all, just in asking other people to do it for you and then complaining when they say no or giving excuses for why you won't do it. It's completely unreasonable, and because of that, this will be my last post in this thread. I should have stepped out pages ago...

Richard Cranium · 11-07-2019, 05:10 PM

Quote:

Originally Posted by igadoter

Yeah, I figured out that there is bunch of over authoritative people here. They always know better.

Self-reflection is not your strong point.

drgibbon · 11-07-2019, 10:40 PM

Wow, this thread is still going

Geist · 11-12-2019, 06:43 AM

Desktop/system programming has less change than "Oh, it's time for another framework! Golly!" for web development, but things still get cattywompus.
MPD, for example, Music Player Daemon changed its build system to meson "recently" and that threw me for a loop cause I didn't know it, still only know the basics, so getting that to work was a bit irksome.

What does that mean for the easy to read abstraction slackbuild generator language?
Even that would require updates and maintenance for the user. Granted, it would still be less cryptic than bash (although that really is not a big deal), but *still*.
Unless you have someone better qualified to do everything for you all the time and you only get the cooked meal in the end, you'll need to stay on your toes at least a little bit.

And since humans have great learning capabilities (and some time ago computers were mostly ran from the terminal, and basic programming was the standard go to everydaymans scripting), why not just go full bash if you're going to have to learn and keep up to date with something in this case?

In other words: Maintenance will always be required, and I don't really think it's worth the trouble to make something like this...especially since bash opens up so many things.
It's like putting in the time to learn vim, it's more complex than nano at first glance, but once learned it's just as simple, yet can do so much more so much easier, and vim isn't hard to learn, it's just potentially a LOT of it.

Edit:
Think of it like languages in a country.
Would you tell me I should point to my mouth going "Ah ah!" when I'm hungry when visiting your country?
Should I put my clasped hands to my head and tilt it and making snoring sounds when I am sleepy?

Those are simple.
Or would it be better if I sat down with a dictionary for a while and learned to say "I am hungry, where can I get something to eat here?" in your language?

People are nice and understanding, so I would actually say it would be possible to get by communicating like that...at least on super basic homeless like substistence and squalor...
But why learn the ways of that lifestyle when I could just put a LITTLE bit of effort into something I intend to get serious about a little bit.

bassmadrigal · 11-12-2019, 03:26 PM

Quote:

Originally Posted by igadoter

First of all it is needed to provide many description. Next step on such descriptions is to extract things which are common This should allow to create abstract of script. Having abstract one can now go opposite way. Forget about script and focus only on script abstract. Now script is described in abstract language - there is engine which take this description and produces real script. Of course final script doe not have to follow sbo scripts. But it should do the same job. Once package is being created script goes into trash. Abstract description remains.

Maybe it would help to know what the ultimate goal is...

Because if someone doesn't understand enough bash to read through and tweak SlackBuilds, are they going to understand how to state they need to use a python building system and to move this file to this location and build a python3 version if python3 exists? Or if they need to throw extra options at autotools or meson build systems?

SlackBuilds are relatively simple. What you seem to be looking to do is make it even simpler at the front end for an extremely convoluted and difficult backend. While it might make the entry to creating a SlackBuild a bit easier, what's going to happen when the resulting package doesn't work as expected, or something else in the system changes and breaks things? The SlackBuild maintainer (at least for SBo) is expected to at least have a rudimentary understanding of the program and how to do some basic troubleshooting.

If you as a SlackBuild maintainer tell a program to, "extract the source, build the program, package the program", are they going to be able to provide any sort of assistance if someone runs into a problem with it?

Here is one of my simpler SlackBuild scripts, as it is just repackaging a deb package for discord. If I were to "free language" this, it would probably be something like:

Set name, version, build number, and tag, where to find all the files, where to extract the program, and where to stage the files.
Only allow package creation on 64bit systems.
Extract the package.
Set permissions.
Strip binaries and libraries.
Create documentation directory and move required files over to the staging area.
Remove unneeded files.
Move description and post-install files to correct locations.
Create the package.

But then you look at my redeclipse SlackBuild and it needs to extract 37 submodules to the correct locations before you attempt to compile it. Luckily, I was able to automate it with the following code:

Code:

# Unpack the submodules
for SUBMODULE in `cat $CWD/submodules-list`; do
  if [ -d data/$SUBMODULE ]; then
    rm -r data/$SUBMODULE
  fi
  tar xvf $CWD/${SUBMODULE}-${VERSION}.tar.gz
  mv ${SUBMODULE}-${VERSION} data/${SUBMODULE}
  if [ -e data/${SUBMODULE}/.gitmodules ]; then
    rm data/${SUBMODULE}/.gitmodules
  fi
done

SlackBuilds seem to be the perfect mix of simple yet powerful. You can go simpler with additional programs, but those programs are going to be extremely convoluted and may not work for every case and in some cases, you will still need to know coding. I know one example is slkbuild. This uses a more ebuild like system, which can simplify some aspects, but could add complexity in other areas that don't fit the cookie-cutter SlackBuild approach.

If you want to look at my most complicated SlackBuild (which still pales in comparison to some of Eric's SlackBuilds like vlc and some official Slackware SlackBuilds like X), it is my amdgpu-pro SlackBuild. I have it pretty well commented, so you should be able to grasp what is going on, but could you imagine trying to get a tool to just handle all that and how complicated the backend of that tool would be?

Richard Cranium · 11-13-2019, 03:19 AM

Quote:

Originally Posted by bassmadrigal

Maybe it would help to know what the ultimate goal is...

Well, there are things that are possible, things that might be useful, and things that aren't worth the effort to be made useful. (And things that aren't possible as well as things that aren't useful.)

So how can you figure out into which category a data-driven slackware package build system belongs? Well, you'd look at how it's done now and attempt to abstract out the parts that are common and the parts that aren't.

To be honest, I think the OP is going about this the wrong way. I happen to believe that what I think the OP is doing belongs in the "things that aren't worth the effort to be made useful" bucket. That doesn't mean that I'm right and he/she/it is wrong. Maybe what the OP is attempting to do isn't worth the effort to be directly useful; it might, OTOH, lead us all into something that actually is useful.

Your mileage may vary.

bifferos · 11-13-2019, 03:55 AM

Quote:

Originally Posted by Richard Cranium

I happen to believe that what I think the OP is doing belongs in the "things that aren't worth the effort to be made useful" bucket. That doesn't mean that I'm right and he/she/it is wrong. Maybe what the OP is attempting to do isn't worth the effort to be directly useful; it might, OTOH, lead us all into something that actually is useful.

Abstractions done right are always useful overall, the problem is doing them right. What you have here is almost a sliding scale of possibilities, ranging from

MSI + InstallShield, tables DB format etc...
Ansible-like: abstracted descriptions of steps driven by a modular architecture, expressed either as json, yaml, xml unless you want to go nuts and create a domain-specific language (yuck)
Switch to an easier language to write abstractions in (e.g. Python) and create a helper module to do the heavy lifting. I'm liking this more because at the very least it avoids coining a DSL/Interpreter that everyone has to learn, but I see a lot of value in a build system that doesn't depend on Python.
Getting more idiomatically Slackware: Shell function library installed on the system
A standard (versioned) shell function library that sits alongside the main slack build script to take away some of the boilerplate. This means duplication between SlackBuilds, but I'm sure we can all live with that. It's not going to amount to much.
A code generator that, given some basic parameters generates your boilerplate script which you then hack.

Much as I dislike Bash, the last two seem the best fit given where we are now and the skill set of most SlackBuild maintainers.