On 05/11/16 13:59, Daniel Prosser wrote:
I like David's suggestion of making sure we know exactly what problem is
going to be solved by this and how much work is going to be needed
before deciding to go ahead and do it (i.e., looking through all the
SlackBuilds and keeping track of all the different ways optional
dependencies are handled, and then making a decision). If this is too
complicated to be included in the automated tools without programming in
handling for a ton of possible permutations and edge cases, which I
think it might be, and there is not another significant benefit to it,
then there's no point in doing in. If, on the other hand, it does make
life better for the users and maintainers, then it might be worth it.
But that needs to be determined first.
I do agree that it has to be investigated, that is a must.
What problems are going to be solved, I already have mentioned.
Willy does not agree with me, it is his rightful opinion, just different
from mine.
I really get frustrated when searching for optional packages.
But when it comes to differences in handling optional parameters between
different SlackBuilds, then why not force maintainers to do it in a
standardized way?
We had no problems on forcing using 'find' instead of 'chmod -R', why
would this be different?
Standardization is good, to the benefit of all.
And remember, it does not have to all happen at once.
I see no problem with it being an incremental process.
The presence of OPTIONAL field in the .info wouldn't disturb the
automated tools, but if so, they can be easily fixed.
What could disturb them, is standardization of handling of optional
parameters, if the change was incompatible.
--
Best regards,
Andrzej Telszewski
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/
