LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-05-2019, 02:12 AM   #61
chemfire
Member
 
Registered: Sep 2012
Posts: 234

Rep: Reputation: Disabled

Years of software development has taught me there are three types of abstractions.

1)
Complex well thought out ones that grant uniformity (map things to language semantics and make them orthogonal to other constructs) which generally don't hide complexity

2)
Simplifications that are well thought out covering the most common usage and don't attempt deal with corner cases. An example here might be an ORM it will provide you with a simple reliable way to do do 99% of the CRUD operations your application needs; you still write a SQL statement to handle that super complex report.

3)
Naive abstractions where the author did not understand or appreciate the problem domain, does not realize how limiting their solution is and how frequently user will run into the walls and does not realize their solution forces really kludgey workarounds because they never understood the right way to do the job in the first place... (This sadly is the most common form)


What the OP does not seem to understand is that Slackbuilds are solving a very complex problem. Here is your natural language description of what Slackbuild is: "Its a non-interactive script that builds a slackware package for software or shared data files from some number of file or URL based inputs." Good luck writing an abstraction for that its to big a domain. The best you can do is some templating like the really excellent work Alien Bob has already done.

As much as the Rubists and Pythonistas want to believe otherwise you can't boil everything in computing down to a single call to Universe.makeMeASandwhich(). This only works as long as everyone wants a PB&J. It all comes apart the moment someone wants a grilled cheese and god help you if someone orders the Monte Cristo. While they all still share some common features, suddenly we are not even trying to spread things on the same side of the bread. The sensible programmer will go back the drawing board here accepting complex problems require complex solutions and start creating separate procedures. The typical code monkey who does not actually know much about the wide world of sandwich arts will start solving their new problem. Pretty soon they are doing things like; grill(makeMeASandwich({pblevel=>0; jellytype=>:butter}).invert().addCheese(type=:cheddar)) trying to convince themselves this is sensible and clever.

So here back to the OPs objectives. Either back away and accept that a Bash probably is the right level of abstraction for constructing SlackBuilds -or- go the (2) route and restrict the domain. You could probably make a system that handles creating SlackBuild for say applications that start as source using gnu/autotools. You could probably parse the output of ./configure and generate a JSON blob with all the option parameters, and create a script from there. The thing is by the time you specify what you want those to be you could have just put configure --option=blah ... into Alien Bob's template and in about the same amount of time. So we are back to why bother here. Not at all sure what their is to gain..
 
5 members found this post helpful.
Old 11-05-2019, 05:38 AM   #62
brobr
Member
 
Registered: Oct 2003
Location: uk
Distribution: Slackware
Posts: 570

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by igadoter View Post
Seems it is empty space to fill - create distribution for don't-want-learners.
Possibly Windows and Apple are claiming that space. With, what they call, their 'user-friendliness'. In principle I would not tempt to cater for 'Don't want learners' as even running the simple 'normal language' command you have in mind will become problematic. This because the output, a novel program to run on their device, might already be too difficult a concept. Catering for those users, would in the end boil down to a procedure that goes like installing stuff on a smart phone, triggered by update alerts and pressing a lot of 'accept' keys and there you go; all your stuff ready for grabs by data-hungry companies (as the 'Don't want learner' might not want to be aware that some default settings are best turned off immediately). Nowadays, out of self-protection, you have to learn the strength and weaknesses of your tool, to which you could handover a lot of personal information.

In the end I think the availability of bash and things like Slackbuilds - which you can easily adapt for your own installs as they just harness the 'configure/make/install' sequence to obtain a controllable item, a package that can easily be installed/removed from a system - provides a lot of power to users. Learning to use those tools provides (a feeling of) control over your stuff that is lacking when running something like Windows or mobile phone apps.

Don't want learners might best be helped by being encouraged to learn something about their system.

Maybe I have taken above expression of the OP too literally; Maybe he has 'Cannot learners' in mind, who need a very simplistic interface in order to use their system in the first place. That would involve accessibility issues.
 
Old 11-05-2019, 06:18 AM   #63
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,250
Blog Entries: 18

Rep: Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991
Before all these fancy packaging and build systems came along, one would simply type "make install" and it was as simple as that.

How's that for "free language abstraction"?

----
assuming all needed libraries were already installed of course.
 
Old 11-05-2019, 11:55 AM   #64
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 856

Rep: Reputation: 643Reputation: 643Reputation: 643Reputation: 643Reputation: 643Reputation: 643
Quote:
Originally Posted by chemfire View Post
Years of software development has taught me there are three types of abstractions.

1)
Complex well thought out ones that grant uniformity (map things to language semantics and make them orthogonal to other constructs) which generally don't hide complexity

2)
Simplifications that are well thought out covering the most common usage and don't attempt deal with corner cases. An example here might be an ORM it will provide you with a simple reliable way to do do 99% of the CRUD operations your application needs; you still write a SQL statement to handle that super complex report.

3)
Naive abstractions where the author did not understand or appreciate the problem domain, does not realize how limiting their solution is and how frequently user will run into the walls and does not realize their solution forces really kludgey workarounds because they never understood the right way to do the job in the first place... (This sadly is the most common form)


What the OP does not seem to understand is that Slackbuilds are solving a very complex problem. Here is your natural language description of what Slackbuild is: "Its a non-interactive script that builds a slackware package for software or shared data files from some number of file or URL based inputs." Good luck writing an abstraction for that its to big a domain. The best you can do is some templating like the really excellent work Alien Bob has already done.

As much as the Rubists and Pythonistas want to believe otherwise you can't boil everything in computing down to a single call to Universe.makeMeASandwhich(). This only works as long as everyone wants a PB&J. [....] Either back away and accept that a Bash probably is the right level of abstraction for constructing SlackBuilds -or- go the (2) route and restrict the domain. [..]
+1 for everything here.

a SlackBuild is just a file name for a number of scripts that have many similarities, but you could build a Slackware _package_ (which is the real purpose here, surely?) using any tool you fancied, as long as the archive contained some specific files in a certain format an so on.
For example, there's this lovely "slacktrack" tool that takes a commandline switch:
Code:
 -Q,  --standard                Select options required to build a compliant Slackware package
In my mind, if someone doesn't know enough to edit some bash templates, but is going to read the instructions about how to build the software and in doing so, uses "tar", vim, whatever - even if it's literally ./configure; make install then that's not a great leap further to the most basic "SlackBuild" script there is.

But if you have a complex piece of software that actually requires lots of post or pre-processing in order to build a package of it, when you think about it, you're not using "bash" to do this, but bash is simply fork()ing a set of other tools when you hit ENTER. A bash script is simply a way to save you doing it by hand once again.

I cannot see a purpose to consider any such abstraction from these basic realities, and I'd see it as a retrograde step if one were to be made.
Unless of course you just fancied hacking on something to see what you could do. That's an entirely different thing! ;-)

Last edited by drmozes; 11-05-2019 at 11:56 AM.
 
1 members found this post helpful.
Old 11-05-2019, 01:47 PM   #65
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 7,734

Rep: Reputation: 6297Reputation: 6297Reputation: 6297Reputation: 6297Reputation: 6297Reputation: 6297Reputation: 6297Reputation: 6297Reputation: 6297Reputation: 6297Reputation: 6297
Quote:
Originally Posted by igadoter View Post
Instead of let provide simple textual description - no need for bash scripting is required.
Code:
$ sudo make me a package!
 
3 members found this post helpful.
Old 11-05-2019, 01:55 PM   #66
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,051

Rep: Reputation: Disabled
Who is sudo?
 
1 members found this post helpful.
Old 11-05-2019, 07:20 PM   #67
Poprocks
Member
 
Registered: Sep 2003
Location: Toronto, Canada
Distribution: Slackware
Posts: 479

Rep: Reputation: 253Reputation: 253Reputation: 253
Here's an initial prototype. Hope y'all find it to be of use.

free_language_compilation.m4
Code:
define(OK_first_what_were_going_to_go_ahead_and_do_is_prepare_our_toolchain_to_compile_this_software, ./configure)dnl
define(All_right_the_second_step_now_that_the_Makefile_has_been_generated_is_to_actually_compile_the_software, make)dnl
define(Excellent_now_that_the_software_is_compiled_lets_install_it_so_that_users_can_reap_the_benefit_of_actually_being_able_to_go_ahead_and_make_use_of_the_said_software, make install)dnl
SlackBuild-free-language.in
Code:
OK_first_what_were_going_to_go_ahead_and_do_is_prepare_our_toolchain_to_compile_this_software
All_right_the_second_step_now_that_the_Makefile_has_been_generated_is_to_actually_compile_the_software
Excellent_now_that_the_software_is_compiled_lets_install_it_so_that_users_can_reap_the_benefit_of_actually_being_able_to_go_ahead_and_make_use_of_the_said_software
Code:
cat free_language_compilation.m4 SlackBuild-free-language.in |m4 -
 
1 members found this post helpful.
Old 11-06-2019, 05:18 AM   #68
wainamoinen
LQ Newbie
 
Registered: Sep 2009
Posts: 5

Rep: Reputation: Disabled
Maybe you can start by looking some complex .SlackBuild files, you will notice that there are a lot of dirty tricks that are needed to build them: broken dependencies that have to be fixed, system incompatibilities, libraries version incompatibilities, temporal experimental features, bugs to be patched, files that have to be parsed to decide how/what to patch/compile/link, etc. Look for example:
virtualbox https://slackbuilds.org/slackbuilds/...box.SlackBuild
palemoonhttps://slackbuilds.org/slackbuilds/...oon.SlackBuild
qt5 https://slackbuilds.org/slackbuilds/...qt5.SlackBuild
LibreOffice https://slackbuilds.org/slackbuilds/...ice.SlackBuild

There are so many special cases, because every package is a different world. Many are well designed to just ./configure ; make ; make install, but often that is not the case. Some packages require a lot of experience/knowledge to create the build script.

Trying to abstract dirty tricks would be a nightmare.

"Everything should be made as simple as possible, but not simpler."
- A. Einstein
 
1 members found this post helpful.
Old 11-06-2019, 06:10 AM   #69
igadoter
Senior Member
 
Registered: Sep 2006
Location: wroclaw, poland
Distribution: many, primary Slackware
Posts: 1,405

Original Poster
Blog Entries: 1

Rep: Reputation: Disabled
I see we really need to go hard but this will make you feel stupid. But problem is if something is not possible for you it does mean it is not possible at all. First off I was rethinking what I imagine to reach: script by itself is not important. There is textual description and there is a parser which translate this into executable script - what literally is inside script is not important - system is not aimed at creating scripts - but building software. In other words - different parser can provide different scripts - yet these scripts should be functionally equivalent. Say someone who is creating such parser say does not like particularly sbo - for some reason. The scripts generated by its own parser are textually different and they do not follow the template for sbo scripts. Having parser on several instances it is enough to share textual descriptions instead of scripts. Scripts are locally based and never archived - or it is explicitly requested. So where to start? From vocabulary used by scripts, say
Code:
cat -s ostree.SlackBuild | sed 's/ /\n/g'
these are lexical elements, now it is needed to go trough all scripts and vocabulary is ready. Now I think we can play a little game: how many words do you think vocabulary for all scripts would contain? Now let see there are things like CAPSNAME, $CAPSNAME, name, --name, \(, and so on. Now we do statistic - dictionary. Grab word from vocabulary look for how many scripts contain this word. If many then supposedly the word should be considered required. At next stage semantic is needed: what these words are stand for? CAPSNAME: variable, $CAPSNAME: reference, name: command, command option. People here said about great of number of compile option flags. Ok.Once vocabulary will be created we will see how many in reality there are option flags. I mean if existed sbo script provided number of options are considered to be sufficient then based on this scheme also should be considered sufficient. Don't ask me to create thing better than those which exists already. Because you ask the same who create scripts for better solution.
 
Old 11-06-2019, 06:34 AM   #70
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,250
Blog Entries: 18

Rep: Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991Reputation: 2991
Quote:
Originally Posted by wainamoinen View Post
Trying to abstract dirty tricks would be a nightmare.

"Everything should be made as simple as possible, but not simpler."
- A. Einstein
Exactly. the shell-script is the easy part in all this. Collecting the right set of patches and choosing the right set of build options is the difficult part.

Abstraction would not aid the unskilled, and would only be an additional layer to learn for the skilled.
 
3 members found this post helpful.
Old 11-06-2019, 07:55 AM   #71
urbanwks
Member
 
Registered: Sep 2003
Distribution: Slackware64-Current, FreeBSD 11.0
Posts: 182

Rep: Reputation: 190Reputation: 190
Quote:
Originally Posted by igadoter View Post
Don't ask me to create thing better than those which exists already.
Ok, I won't.
 
Old 11-06-2019, 08:13 AM   #72
montagdude
Senior Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 1,613

Rep: Reputation: 1251Reputation: 1251Reputation: 1251Reputation: 1251Reputation: 1251Reputation: 1251Reputation: 1251Reputation: 1251Reputation: 1251
Quote:
Originally Posted by igadoter View Post
Don't ask me to create thing better than those which exists already.
As far as I can tell, no one has asked you to do anything. You have asked us to do a lot of things for you. That's not how software gets developed. If you think this is a good idea, just go ahead and start doing it. I really don't understand why you are hanging around this thread arguing about it. Put up or shut up, as they say.
 
Old 11-06-2019, 08:18 AM   #73
Qury
Member
 
Registered: Feb 2004
Location: Dublin
Distribution: Slackware
Posts: 181

Rep: Reputation: 163Reputation: 163
@igadoter
Can you explain a real life scenario where you would see this project used and who would use it? Power users, developers or system admins?

Also can you share a mock version of a script you imagine this to be like?
 
1 members found this post helpful.
Old 11-06-2019, 08:48 AM   #74
igadoter
Senior Member
 
Registered: Sep 2006
Location: wroclaw, poland
Distribution: many, primary Slackware
Posts: 1,405

Original Poster
Blog Entries: 1

Rep: Reputation: Disabled
Quote:
Originally Posted by montagdude View Post
You have asked us to do a lot of things for you.
I asked for free language description of sbo script. Nothing really precise, adequate, just in own words. Do you think this is lot of things? But as usually thread diverged.
 
Old 11-06-2019, 08:59 AM   #75
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,051

Rep: Reputation: Disabled
I don't really understand what you request or suggest, and other's answers make me think I am not alone.

If you provide as an example at least the beginning of a free language description of a very simple SlackBuild, maybe that would help me and others to actually understand what you want.

Last edited by Didier Spaier; 11-06-2019 at 10:07 AM.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Suitesparse /Cuda SBo, complains about too advanced GCC, although being built with GCC 5 from the same SBo. Lockywolf Slackware 5 04-28-2019 11:17 PM
nvidia-driver SBo The symbolic link '/usr/lib/libGL.so.1' does not point to 'tmp/SBo/package-nvidia-driver/usr/lib64/libGL.so.1' Gerardo Zamudio Slackware 5 07-30-2017 11:44 PM
Questions for Robby, ponce, or anyone from SBo about SBo submission requirements. ReaperX7 Slackware 4 06-07-2015 12:30 PM
Nvidia-driver.SlackBuild from SBo (or: I am a bad and sloppy SBo maintainer) kingbeowulf Slackware 8 08-31-2012 03:41 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:08 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration