[Slackbuilds-users] Orphaned slackbuilds

Frank Caraballo fecaraballo at gmail.com
Fri Nov 2 19:38:01 UTC 2007

Niki Kovacs wrote:
> Martin Lefebvre a écrit :
>> What if, theoratically speaking, Slackbuilds were made so that if a new
>> version comes out, all the user who wants to have the latest and
>> greatest has to do is pass it like ARCH?
>> VERSION=1.0.4 ./prgnam.SlackBuild
>> most new versions will work that way, and if there is a problem, then
>> the maintainer can be emailed, and a new script can be uploaded.
>> IMO, that has the effect of being more adaptable, and at the same time,
>> allows users to have the newest version, but also have an older one if
>> someone prefers the way 1.0.2 worked over 1.0.3+
> IMHO this is a bit of an infringement to the KISS principle. Up until 
> today, I've used 50+ scripts from SBo, and I only remember one occasion 
> where a script offered (and still offers :oD) an outdated version, 
> that's yaz (php-yaz needed a more recent version to build). I just took 
> the script, altered the version number myself, made a few adjustments, 
> and everything was fine.
> A more straightforward solution would be to simply ask users to take a 
> peek once in a while.
> [Aside: I didn't offer much help up until now, because I spend 14 hours 
> a day on a project that I have to finish until the end of November. The 
> project consists essentially of replacing all our CentOS and Debian 
> desktops by an XFCE-based Slackware desktop with numerous 
> enhancements... As soon as the first two dozens of machines are 
> installed and run fine, I'll gladly return something to SBo. I have many 
> SlackBuild scripts here that aren't on slackbuilds.org... I'm planning 
> to adjust them a bit so they are SBo-compliant, since my scripting style 
> is a bit different.]
> Maybe submitting scripts is a bit like kids. It's not enough making 
> them, you have to look after them once they are out in the world :o)
> cheers,
> Niki
> _______________________________________________
> Slackbuilds-users mailing list
> Slackbuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Please read the FAQ - http://slackbuilds.org/faq/
I agree that scripts should only be updated when a new version will not 
compile without tweaks. The maintainer shouldn't have to submit a 
updated script if a simple version change is all that is required 
(unless they decide too). I do think, however, that for a major Slack 
version that more time should be spent making sure quality is up to snuff.

It was very noticeable, to me anyways, that the quality of scripts was 
down because of the push to have everything ready for 12.0. I personally 
spent a lot of time updating and testing my scripts only to have someone 
else submit an update simply because '12.0 was coming out soon'. Many of 
these updated scripts had small errors. One was missing a config file 
that was there in the old script but was taken out in the updated script 
making the program useless. One was updated to a version that was known 
to have issues working correctly simply because it was a newer version. 
Quality issues like this should have never arose in the first place.

IMHO, the authors ARE the maintainers of the script unless they 
specifically ask not to be (or if the SBo team feels like they can tweak 
the heck out of a script and get it all automated or some such thing). 
Once they ask not to be (as Michael did) is when there should be a 
maintainer added to the script.

The SBo team should only accept script updates from either the author or 
the current maintainer. If a quality issue arises, the SBo team then 
knows where to take the complaint(s). Update requests should be directed 
to the author or the current maintainer. The SBo team shouldn't have to 
respond to these requests. As a result, the quality of the scripts will 
improve and the database should be more up-to-date.


More information about the Slackbuilds-users mailing list