LinuxQuestions.org
Visit Jeremy's Blog.
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 09-09-2020, 06:59 PM   #1
jmpz
Member
 
Registered: Jul 2012
Posts: 58

Rep: Reputation: Disabled
Thoughts on slackbuilds.org


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.
 
Old 09-09-2020, 07:50 PM   #2
Daedra
Senior Member
 
Registered: Dec 2005
Location: Springfield, MO
Distribution: Slackware64-14.2
Posts: 1,620

Rep: Reputation: 424Reputation: 424Reputation: 424Reputation: 424Reputation: 424
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.

Last edited by Daedra; 09-09-2020 at 09:38 PM.
 
3 members found this post helpful.
Old 09-09-2020, 07:52 PM   #3
montagdude
Senior Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 1,790

Rep: Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370
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.
Old 09-09-2020, 08:22 PM   #4
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 7,323

Rep: Reputation: 5034Reputation: 5034Reputation: 5034Reputation: 5034Reputation: 5034Reputation: 5034Reputation: 5034Reputation: 5034Reputation: 5034Reputation: 5034Reputation: 5034
Quote:
Originally Posted by jmpz View Post
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.
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.
Old 09-10-2020, 12:40 AM   #5
jmpz
Member
 
Registered: Jul 2012
Posts: 58

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Daedra View Post
The current system works, no need to fix something that isn't broken.
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.

Quote:
Originally Posted by montagdude View Post
You could always make a Git repository for your local modifications and just clone that on your new machine.
Do you happen to know if sbopkg supports point to a local SBo repo?

Quote:
Originally Posted by bassmadrigal View Post
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.
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...

Last edited by jmpz; 09-10-2020 at 12:46 AM.
 
Old 09-10-2020, 12:52 AM   #6
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 5,593

Rep: Reputation: Disabled
Quote:
Originally Posted by jmpz View Post
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? 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.

Last edited by ponce; 09-10-2020 at 01:15 AM.
 
2 members found this post helpful.
Old 09-10-2020, 01:22 AM   #7
jmpz
Member
 
Registered: Jul 2012
Posts: 58

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ponce View Post
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.
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!
 
Old 09-10-2020, 01:41 AM   #8
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 5,593

Rep: Reputation: Disabled
Quote:
Originally Posted by jmpz View Post
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.
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...
Quote:
Originally Posted by jmpz View Post
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?
unfortunately an automated build system won't, IMHO, be enough because it won't test for incompatibilities at runtime...

Quote:
Originally Posted by jmpz View Post
Do you happen to know how does Debian or Arch maintain their pkg repo? Also dedicate to each pkg maintainer?
yes, they have a maintainer for each script/package (with one main difference: SBo doesn't distribute packages).

Quote:
Originally Posted by jmpz View Post
Thanks for your discussion!
well, this is actually not the proper place for a discussion like this, it will be properly suited in the slackbuilds-users mailing list.

Last edited by ponce; 09-10-2020 at 01:48 AM.
 
2 members found this post helpful.
Old 09-10-2020, 03:01 AM   #9
average_user
Member
 
Registered: Dec 2010
Location: Warsaw, Poland
Distribution: Slackware
Posts: 534

Rep: Reputation: 212Reputation: 212Reputation: 212
https://github.com/SlackBuildsOrg/slackbuilds
 
Old 09-10-2020, 05:12 AM   #10
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 1,289

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
Quote:
Originally Posted by jmpz View Post
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?).
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.

Quote:
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.
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.

Last edited by chrisretusn; 09-10-2020 at 05:16 AM.
 
2 members found this post helpful.
Old 09-10-2020, 05:55 AM   #11
EdGr
Member
 
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 483

Rep: Reputation: 234Reputation: 234Reputation: 234
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.
Old 09-10-2020, 09:57 AM   #12
montagdude
Senior Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 1,790

Rep: Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370
Quote:
Originally Posted by jmpz View Post
Do you happen to know if sbopkg supports point to a local SBo repo?
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.
 
Old 09-10-2020, 10:00 AM   #13
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 256

Rep: Reputation: 105Reputation: 105
Quote:
Originally Posted by EdGr View Post
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
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.
 
Old 09-10-2020, 10:05 AM   #14
drumz
Member
 
Registered: Apr 2005
Location: Scottsdale, AZ, USA
Distribution: Slackware
Posts: 256

Rep: Reputation: 105Reputation: 105
Quote:
Originally Posted by jmpz View Post
Do you happen to know if sbopkg supports point to a local SBo repo?
Yes:

Code:
sbopkg -V local -k -b ffmpeg.sqf
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).
 
Old 09-10-2020, 07:51 PM   #15
thirdm
Member
 
Registered: May 2013
Location: Massachusetts
Distribution: Slackware, OpenBSD, NetBSD
Posts: 212

Rep: Reputation: Disabled
Quote:
Originally Posted by drumz View Post
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.
"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?
 
  


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
openbox on slack13.37 (x86) -- Thanks to linuxquestions.org, slackbuilds.org & many vectrum Linux - Member Desktop Screenshots 5 02-03-2013 12:22 PM
slim pkg from slackbuilds.org symatic Slackware 3 07-14-2007 02:53 PM
[slackbuilds.org] slackware repository idea arcanex Slackware 5 05-19-2007 09:19 PM
Use SlackBuilds.org or my own hosting to offer up SlackBuilds? hollywoodb Slackware 6 11-30-2006 08:56 PM
SlackBuilds.org Frozen Bubble not working... Lufbery Slackware 7 11-07-2006 01:54 PM

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

All times are GMT -5. The time now is 07:43 AM.

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
Open Source Consulting | Domain Registration