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

[David Spencer]

Folks, I'm going to reply to a lot of different people in this post.  Sorry!

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

>> 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.  It's one
more thing to go wrong, in a world where newbie maintainers can't even
get the slack-desc right.  It's one more way for reviewing admins to
make mistakes and approve something that's broken because README and
OPTIONAL say two different things.  That's not a total NO from me, but
it makes me worry a bit :(

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.  And then I think we are going to
need to bring %README% back again, for cases where we need to say
"it's really complicated, you *must* read the README".

(But previously, people didn't understand %README%. Some maintainers
would always put it in, because it looked pretty.  So now, it really
means "This Package Clashes With Something In Slackware".)

> Implementation by the backend of SlackBuilds.org
> and package building tools (sbopkg/sbotools/slpkg) is another
> subject which is not important now, because we should let the
> maintainers of these tools (and Slackbuilds.org) decide if they
> implement this field or not.

But what's the point of a machine readable field that isn't being read
by the machine?  The tool maintainers would pretty much *have* to
implement it, otherwise you're all going to be very disappointed.

> In the worst case, if we agree how the format of OPTIONAL
> should look, we don't have to put this field in *.nfo,
> we can put it in the README or README.slackware or even create
> a dedicated SaaS returning the OPTIONAL value for each
> package via SOAP API call ;-)

Congratulations, you just reinvented slackrepo's hintfiles. You are
welcome to write a scraper to get the ADDREQUIRES fields from my
github. It would force me to update them properly :)  And there's lots
of other good stuff in there -- like what options are needed to enable
those deps, and which ones need -j1 to build.

Finally --

When I said we need to define the problems we currently have, I did
have two specific things in mind.

One: occasionally in the README files, there are mistakes in the
package names. Sometimes it's an upper/lower case error, or someone
has forgot (for example) "python-", or whatever.  I was going to audit
the whole lot before 14.2 came out, but didn't.  Sorry.  Anyway, this
still needs to be done.  If you see any mistakes, please do tell us.
Thanks in advance!

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.

I'm generally a believer in "fix the technology, not the people".  But
I don't see how to avoid falling back to README when it's complicated.

Maybe we should give some thought to making README files nicer to use.
Maybe they should become more like manpages, with less random
description and with standardised headings and layout.  Markdown?

Maybe we should hide some prizes in README files, like someone once
did with a licence agreement. ;-)

Can I just say one more thing?
Thanks to everybody for caring so passionately about SlackBuilds.org :D
-D.