[Slackbuilds-users] Orphaned slackbuilds

[alkos333]

On Nov 3, 2007 5:18 AM, LukenShiro <lukenshiro at ngi.it> wrote:

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

I don't really see a problem with the current system.  If you would
like to see if the package is in pending and what the script looks
like, you can always obtain it like so:
http://slackbuilds.org/pending/<package_name>.tar.gz

> - to have some reviewers, maybe also among other packages' actual
> maintainers (if available), in order to speed somehow package's
> analysis and approval.

This will certainly create more trust, but I doubt it will speed up
the package processing because team members will most likely want to
test everything for themselves.

> - 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).

This is always a good coding practice to doc your source  and
emphasizing that in the policy wouldn't hurt.

> - to ask to Patrick for incorporating some management function in
> pkgtools (such as 'config()', for managing .new files' installation)
> instead of doinst.sh.

I don't t think there is a safe way of merging two files without
breaking things.

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

Sometimes there are quite few things being compiled by default :).
Sounds like a deterrent for submitting a package to me.
One can always  run ./configure --help and find the necessary info in there.

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

This would be a cool thing to have because stats are always fun, but I
doubt it would influence the level of maintenance.  Think about it,
the more people use a certain package, the more likely they are to
report bugs and as we already know, this team is very swift about bug
fixes.



Regards,
alkos333