I'm wondering why not letting slackbuilds repository support `pull request` as supported in major git services (like github)? Then everyone can contribue and update the build scripts. Currently, if I understand it correctly, only the script owner can update it (is it true?).

I have many local modifications of build scripts but most of them is simply bumping the version. When I install a new machine, I have to manually bump version (and checksum) again, which is tedious and can be avoided if build scripts can be updated more frequently.

Yes only the build maintainer or the devs can make modifications. This is to keep the quality of SBo scripts high. If they start letting anybody just make modifications then broken scripts will inevitably happen and overall quality will go down. The current system works, no need to fix something that isn't broken. If you have scripts that have legitimate fixes or updates then contact the maintainer. If they do not respond, then usually the devs will allow you to take over maintenance of the package.

3 members found this post helpful.

You could always make a Git repository for your local modifications and just clone that on your new machine.

SBo does support Git, but they don't just let anybody push to it. And you are correct that only the maintainer can update a script.

2 members found this post helpful.

The thing to keep in mind is SBo wants stable packages, however, the admins leave it up to each maintainer to decide what "stable" means to them. For some maintainers, it's updating every release, others will hold onto a known working package until there is enough reason to upgrade it, others might hold back an upgrade for a specific reason.

I don't follow anything specific with the packages I maintain. Some, like discord, I update as soon as there's an update available (especially since there is an upgrade notice within the app), others, like meson, I upgrade whenever I get an inkling to do so. I upgrade mediainfo whenever I happen to notice there's a new version. Some, like enki, simsu, qutepart, picard, etc, I haven't updated to newer versions to prevent introducing qt5 as a dependency (which I will upgrade once 15.0 comes out or I get a request from someone to support the qt5 version). I don't want to force someone to compile qt5 just to have a newer version (although, I know a lot of people get qt5 due to dependencies of other programs.

However, I'm always open to suggestions to upgrading. If someone emails me requesting an update, as long as I don't think it'll break other packages and the update itself looks good, I'll push it.

4 members found this post helpful.

Not a fix but a potential improvement (and I could be wrong). I'm trying to brainstorm any way to simplify the script upgrade and easy the burden of pkg maintainer. Please take a look at comments below.

Do you happen to know if sbopkg supports point to a local SBo repo?

Valid concern. I agree that let pkg maintainer own the script is probably the most stable way. I'm looking for a more convenient way that allow community submit pull request to the pkg maintainer. Currently if I want to update one script, instead of file a git request, I need to: 1) contact the maintainer probably via email with attached diff; 2) if no response, I need to forward that email to SBo devs and transfer the ownership.

Can we replace these 2 steps with a single pull request? The original pkg maintainer still make the call to decide whether one pull request is acceptable or not. I feel sometimes I'm too lazy to contribute local modifications back to SBo repo because of these 2 additional steps...

I strongly advise against changing that because it will mean that when you and everybody else will send the pull requests to the maintainers or the SBo admins, for each one of them they will have to:
- test the new build;
- test the update against whatever needs it as a dependency;
- contact the respective maintainers and track their answers;
- if the maintainer is unresponsive try to find a new mantainer.
it's much more practical when these steps are done by whoever is interested in the update (and is ready to step in as a maintainer himself) and has tested it locally.

2 members found this post helpful.

One way I'm thinking of to easy maintainer's work is that: when anyone sends a pull request, one must prove that new changes have passed the first 2 tests you mentioned, i.e., affected/dependent pkgs can be built. Some options in my mind:
1. Set up a auto build system, and it'll build affected pkgs if any associated files are updated due to the new pull request. But this option definitely requires lots of CPU cost, which is currently spent by each maintainer.
2. Is there anyway to build some sort of signature to tell if one request doesn't break affected pkg build?

Do you happen to know how does Debian or Arch maintain their pkg repo? Also dedicate to each pkg maintainer?

Thanks for your discussion!

sorry, how do you prove it? logs won't be enough because there is no assurance on which platform they have been produced (slackware version, packages installed and so on).
this is something that is left to just the maintainers to guarantee...
unfortunately an automated build system won't, IMHO, be enough because it won't test for incompatibilities at runtime...

yes, they have a maintainer for each script/package (with one main difference: SBo doesn't distribute packages).

well, this is actually not the proper place for a discussion like this, it will be properly suited in the slackbuilds-users mailing list.

2 members found this post helpful.

Well everyone can already contribute thru the maintainer. I don't think it is a good idea to allow everyone to push changes directly. This could very easily get out of control.

I must be missing something, I do not understand your last sentence. Why do you have to manually bump version (and checksum) again when installing to a new machine? Do you not save the modified SlackBuild script? I'm totally lost on having to bump the checksum. The checksums on SBo have no real use for a local build other than to verify the source tarball(s) you download from SBo. If you are downloading a newer version of the source from the developer, then you should be verifying that tarball bases on information provided from the developer. Could be I need more coffee.

A long time ago when I used SBo for building packages. I downloaded the SlackBuild tarball and extracted it to my build tree. That was normally the first and last time I did that unless there was major changes. Over time many of those scripts had changes from the version on SBo. Most of those changes were version bumps. I saw no need to download from SBo again, I just reused the script. I also saved the packages that were built. Eventually this developed in to a local repository of builds and packages.

These days, I build all of my SlackBuild scripts from scratch from a template of my design. I have a 130 SlackBuild scripts in my local repository. Not a single script is from SBo except for their templates which I keep refreshed from time to time as a reference. I still use SBo, but only as a reference, mostly to see how the maintainer did it and usually only if I have issues building. I see SBo as a starting point for building third party packages. I eventually wanted to do more with my scripts. Things you can not do with SBo scripts. If I decide to start contributing to SBo, I will have to change my ways or keep two versions of the scripts of the programs that I would be maintaining.

A build can be done in different ways from the way the maintainer chose. This is another reason the everyone should not be allowed to push changes to SBo.

2 members found this post helpful.

The SBo scripts are really only a starting point. I modify every single one to use the most recent version, run on -current, and install in ~/.local.

If anything could be improved, it is that SBo needs to rethink its strategy of targeting -stable. That worked well with yearly releases, but does not work well now.
Ed

3 members found this post helpful.

I'm not sure if I understand the question. sbopkg always downloads a local copy of the SBo tree. There is also git access. If you want to make changes and have them preserved, I would recommend making a branch for your local changes. Then when you want to update, do a git pull on the master branch and then merge master into your branch.

The system works well for me. All my machines run stable.

OP, some maintainers publish their working trees on GitLab or GitHub. There are currently 29 forks at GitHub (https://github.com/SlackBuildsOrg/slackbuilds) and 31 forks at GitLab (https://gitlab.com/SlackBuilds.org/slackbuilds). Of course, not every maintainer does this. If you preferred to send me a pull request over an email I would be fine with that.

In my observation (this may not be the official SBo stance!) SlackBuilds.org follows the "email is the one true source of communication/lowest common denominator" model. You'll note that every package on SBo has the maintainer's email so you can contact them if necessary. Additionally, there is a mailing list (https://lists.slackbuilds.org/mailma...ckbuilds-users). Everything else (git, for example) is just dressing on top. New submissions MUST use the submission form on the website, which, I assume, triggers an email to the admins.

Your suggestion would require somebody (you?) to add machinery to recognize which SlackBuild the pull request is modifying, and then send an email to the appropriate maintainer. In my opinion, if you want to send a pull request, create your pull request by emailing the maintainer (and optionally the user's list) your public tree with pull request. It's then up to the maintainer to either pull or your changes or examine them manually and incorporate them into the next update.

Yes:

My "local" tree contains my testing tree for potential updates to my SlackBuilds.

But for actually compiling packages I use the stock SlackBuilds.org git tree (the sbopkg default).

"git-format-patch(1) to prepare and send suggested alternative to contributors." -- giteveryday(7)

Isn't git itself supposed to also treat email as the one true source of communication?

This article may overstate the case, but all the same, if slackbuilds isn't promoting gitlab's add on features good for them. gitlab seems not as bad as github but it's a good thing to inoculate as many people as possible against that avenue for lock in:
https://drewdevault.com/2020/08/27/M...heir-hand.html

What's unclear to me, and this would be me needing to read the mailing list more again and maybe review the website again, is what kind of help is desired. Having 10 people send you a version bump patch is probably no fun (or one person sending you 10 version patches for 10 of the slackbuilds you maintain).

The mailing list periodically says what packages were orphaned or what help would be appreciated doesn't it? Am I mixing it up with something else? If you're looking to help them you should look for that kind of message. If you want your life made easier by having them follow your marching orders, well maybe you should think over what you're asking for and what the life of a person who maintains free software has become in 2020. There were articles on this subject not so long ago.

My general impression is that a slackbuild is typically the author's thing, so unless they ask for help they'd probably prefer to do the work themselves on the packages they've adopted, particularly when it's trivial stuff or when there are judgement calls about whether a new version is better. I suppose it would be all too easy for slackbuilding to become clerical in nature where all you do is apply the patches people send to you. Where's the fun in that?