[Slackbuilds-users] Orphaned slackbuilds

[LukenShiro]

venerdì 2 novembre 2007, Niki Kovacs ha scritto:
> Why not simply follow Slackware releases for updates? I'll clarify my
> previous suggestion. Currently, the slackbuilds.org repository offers
> builds for Slackware 11.0 and 12.0. Now say 12.1 comes out - in a
> year? - then it will be time to move over every script, one by one,
> from the 12.0/ directory to the 12.1/ directory... and at that time,
> a check can be made if versions are up to date. Which would mean
> something like a few weeks' worth of work, and then rest on our
> laurels for a year or so, until 12.2 or 13.0 comes out :oD

Sorry, but I do not absolutely agree ;-)
Besides exceptional cases, global effort (and time) required to update a 
script to a new version is normally less than introducing a new package 
(retrieving a convenient description for slack-desc is the thing I hate 
more .. after packages that have so many dependencies to be built, 
obviously :-P).

I second the opinion for which package update should not be done 
blindly: a new version is not necessarily always a better version to 
use / to manage (so the author-maintainer is responsible for the 
operation's convenience); but updating only one time a year or so IMVHO 
is indeed a bad policy that can be somewhat loser in slackbuilds' 
appeal for general users out there. Even in Slackware the package 
making process passes through an ongoing maintenance stage (that is 
current), although not _every_ incoming version is provided.
Anyway some packages are not upgraded upstream really often, so 
upgrading effort is even minor.

P.S. I would have only a few advices who perhaps should help to make 
easier script management:
- to have a web page containing a list of pending package, to avoid a 
possible duplication of work.
- to have some reviewers, maybe also among other packages' actual 
maintainers (if available), in order to speed somehow package's 
analysis and approval.
- to indicate in package's submission policy the need of documenting 
particular points in the scripts that diverge from traditionally making 
way (configure / make / make install / makepkg).
- to ask to Patrick for incorporating some management function in 
pkgtools (such as 'config()', for managing .new files' installation) 
instead of doinst.sh.
- probably, most of ./configure flags should be provided in scripts even 
if some of them are considered as default by upstream developer, to 
define a better "stability" from time to time, between a previous 
version of a slackbuild script and the next.
- a sort of download counter would allow us to evaluate public interest 
in individual packages, therefore a need of higher or lower 
maintainance to follow users' expectations.

Thank you and regards.

-- 
GNU/Linux * Slackware 'current'
LU #210970 LM #98222 SU #12583
"Warning: Trespassers will be shot.
Survivors will be shot again."