[Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]
atelszewski at gmail.com
Sat Nov 5 14:24:30 UTC 2016
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
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
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.
More information about the SlackBuilds-users