[Slackbuilds-users] Orphaned slackbuilds
lukenshiro at ngi.it
Sat Nov 3 10:18:51 UTC 2007
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,
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."
More information about the Slackbuilds-users