In my understanding this added layer needs work and brings nothing. If I am wrong please tell us what it brings to whom that could convince someone to do the work.

3 members found this post helpful.

You can't say if you don't try.
I never asked to do work for me. I can handle myself. Just task as I see this now is not very difficult. I have already picture about contents of script being generated - and how to achieve this. I remember one sentence from Through the Looking-Glass, and What Alice Found There. It is White Queen. She said: to stay in place one needs to run very fast.

Edit: I can only add @Didier that you have very unfair way to discuss matters. You are using poor rhetoric which should eliminate you from any serious discussion. Oh, yeah Schopenhauer dialectic. Aimed at winning discussion as it would be kind of free fight with no rules at all. Shortly: providing opinion provide also arguments. But there is no arguments supporting you opinion. It is something which just hangs in air. The whole work to look for arguments is put on me. This is unfair.

Nobody wants to try if they don't see the benefit behind it. If they don't foresee the effort to be beneficial, it would be wasted time.

It looks like your goal is to make the entry to become a package maintainer easier, but is that really what we want? When problems arise in a package, the package maintainer is the first person that people should go to to find a fix. If the maintainer is only able to provide "free language" to generate the SlackBuild, are they going to be in a position to troubleshoot when things go wrong? If a sed needs to be added to modify some source file or adding a patch to the build, is a maintainer who is only capable of "free language" going to be able to write the words needed to do that? And is the generator you're planning going to be able to support various phrases to do the same thing (build program, compile source, generate program, etc), or is it going to just require the person to learn new commands to make sure they are typing what the generator is capable of understanding?

That is what I don't understand, for the most part, maintainers don't need to touch most of the commands in the SlackBuild. All they really need to tweak are what documentation needs to be copied over and the actual compiling commands (for most packages). For the compiling, they will need to have at least a rudimentary understanding of how to build software in Linux, which likely means they have a rudimentary understanding of the command-line in Linux.

2 members found this post helpful.

Who we? Are you kind of voice of people?
troubleshoot what? If maintainer would build package on its own system - then build cannot fail with the same set of build options. I can imagine only one situation when build would supposedly fail - it is when dependencies were built with different set of options. Different on maintainer computer and different on user computer. But one can solve this two way: versioning of packages, keeping history of builds by collecting used descriptions. But essentially if still will be something wrong finally we would find out what try to take care of this - so it wouldn't happen again. It can't be perfect from very beginning. Reality will show every possible lacks.
it is situation where maintainer rather should ask upstream for revision. If software is already dead - why take care at all? People who will decide to run such thing are pure clean on they own.
earlier I posted about validation - to make sure description has some sens. Things required, optional - this is entry to build script. Once script is created things go on as usually - in simplest form sudo ./foo.buildscript. Generator should be a parser looking for fixed phrases and corresponding values. Phrases are in free language: "compiler flags", "build flags", "name", "version", "architecture" and so on.

I think that's oversimplifying things. Obviously you never dealt with compiling and packaging software that actually someone needs to use.
All your contributions are purely theoretical and hypothetical until now. I suggest you create a git repository and start coding up some rough idea of what you see as a viable product. I will state again - all talk and no action, makes for an extremely boring thread. Until your solution can build a working 32bit Chromium package for me, I am not going to have faith in this endeavor.

6 members found this post helpful.

I didn't say "We don't want that", I asked if it is something "we", Slackware users, would want. I know what my answer would be, but I don't know what all of Slackware users would want.

Have you not been paying attention on the forum? There's a lot of posts that talk about having problems building software. Even more on the SBo mailing list. There's changes for Slackware (both stable and -current) that can happen at any time and can break compiling packages. Sometimes those issues are posted on the forum or the SBo mailing list and other times they're mentioned directly to the maintainer. If the maintainer doesn't understand how a SlackBuild works and can only write the "descriptions", or whatever you're calling the "free language" bits, are they going to be able to do any sort of troubleshooting?

The problems aren't always upstream or upstream may not be willing to fix the problem (maybe it only occurs on Slackware or it's just something they're not willing to fix). And it doesn't help the matter while waiting for upstream to push a fix and/or a new release. If a simple patch or sed can fix it, why should we wait for something from upstream to be able to push a fix out to users? And looking through SBo's repo, there's over 1800 sed commands being used right now and probably a similar number of patch commands.

So, instead of bash commands, you're basically looking to have maintainers learn a new "programming" or "description" language that the generator will support?

Either way, it seems no one is interested in helping you with this right now. So, I think I'm done replying in this thread about a theoretical generator. If you do decide to proceed with this and create a generator, I'd be interested to take a look and possibly contribute to it if I see it being worthwhile. But until this generator is no longer theoretical, it's not worth the back and forth on this thread. I say how difficult it is going to be as you say how easy it will make things. Maybe it's somewhere in the middle... I don't know. But with it being theoretical, it just isn't worth my time to debate the merits of this.

6 members found this post helpful.

did we win yet?

Long time ago I made a SlackBuld (quick and dirty) by copying the ~/.bash_history - but i had to logout for it to be written down first.

Once I pruned the noise out the history snippet, the base was there and i hacked and fudged along until the build worked.

I can't imagine a program of any sort possibly cover the "worst day" case.

Never mind me, but i suspected Slackbuilds might eventually lead to this...

the takeaway is - not all SlackBuilds must end up in an actual package - and still apply being a SlackBuild - there are non published SlackBuilds too

No, you didn't. I am just lying heavily wounded and I am healing my wounds. But will rise again. Like Phoenix from ashes

I hope you heal soon and get Your health back.

I also hope You pick up one of the few SBOs without a maintainer and "carry the cross" for a while.

Once you're over that, You will be ready for your next abstraction layer, meanwhile I recommend to try use sbotools and ponce's -current repository to get the feeling?

I wish I have enough good computer to do the job. The one I am working on is walking zombie.

If that is so, I advise a simple SBo script for the start - i run zombie PCs too