[Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[Franzen]

>>> It's about replicating *THE SAME INFORMATION THAT YOU PUT IN THE 
>>> README*
>>> into the .info file, so *MACHINES* can understand it.
> 
> Somebody would have to verify that it really is "*THE SAME INFORMATION
> THAT YOU PUT IN THE README*", and really there is no way of automating
> that, because the README is only readable by humans.

Yes.
If it comes that far, i'm willling to help by editing several hundreds 
.info-files.

>>> You are not going to test it more than you do already.
>>> Let's finally understand that.
> 
> But we *would* have to *review* more than we already do.

About 15% of all packages are affected with optional deps.
Just a rough find/grep
$ find . -type f -name 'README*' -exec fgrep -i optional '{}' + | wc -l
866

For new submitted packages the admins would have more work, for updates 
very less, as usually dependencies are not changing all the time.

> We *want* SlackBuilds to have a really low barrier to entry. We want
> them to be easy. We are proud that SlackBuilds.org is much easier for
> new people to become maintainers than (for example) becoming a Debian
> Developer.
> Making 'OPTIONAL=' more than a plain list is dooming newbie
> maintainers to one more headache.  So I think that, if we do have
> OPTIONAL, it should be a plain list.

It's really important to keep it simple. In most cases(85%) a maintainer 
won't have to fill the option field at all.
In most cases of the affected 15%, it would be a simple list, like in 
the REQUIRED field.

For the rest(e.g.qemu/spice-gtk and usbredir), the OPTIONAL= field gets 
really interesting and most useful in my opinion, if an OPTION:
- requires the OPTION to build against another package
- makes sense only combined with another OPTION
- conflicts with another package

This rendered on SBo-website would prevent bugreports(two ccured in the 
last months about uncleraness of qemu/gtk-spice,usbredir), as it is more 
obvious that optional packages have to be checked for further optional 
packages, which then may have become a requirement.
Links are more userfriendly, in the current state it's errorprone on the 
SBo-website to copy-paste optional deps from optional deps from optional 
deps to the next browser-tab, where the website has to be opend before.
And that all *because* i want to read the READMEs, i want a better way 
to get the READMEs by OPTIONAL=.
The possibility for 3rd-party automation is a sideeffect, i don't use 
them.
If those tools don't want to fully support syntax like !,&&,(),
these still just could cycle through OPTIONAL= showing the READMEs.

> Two: the single biggest problem we have at the moment (IMO) is qt5.
> Lots of packages don't build properly unless you remove qt5 before
> building.  The only solution we have is to mention it in the README.

If this problem only occurs on compiletime, maybe it
would be solved by implementing something like
"REQUIRED=!qt5" ?


Johannes