> Are we allowed to add slack-required, slack-suggests and slack-conflicts
> files to our scripts?

At the moment, no. If you can find some, it was probably a mistake, or
maybe a specially negotiated exception, but I don't think there are
any :)

*Personal opinions*

slack-required in the SBo repository is pointless, we already have
REQUIRES= in the .info file. When your preferred build tool builds the
package, it can create and package the slack-required file, and/or
create a .dep file, and/or PACKAGE REQUIRED line in a .meta file.

slack-suggests in the SBo repository duplicates the 'Optional
Requirements' in the README file.  sbotools (for example) can read
that!  When the package is built, your options become hard
requirements (with very few exceptions). So slack-suggests in a
package is almost always pointless. Your build tool can add your
*actually* *selected* optional dependencies into the final built
package's slack-required, file and/or the .dep file, and/or PACKAGE
REQUIRED line in the .meta file.

slack-conflicts is a rare case. At the moment we add some advice in
README and we add %README% to REQUIRES=. I would be personally quite
happy to kill %README% forever, by putting a new CONFLICTS= line in
the .info file, which would be more elegant than having a separate
slack-conflicts file. But see below :)

Some more personal opinions:

slack-required potentially has a too-complex syntax. Adding version
constraints is *evil*, it creates an NP-hard problem for your
installer, instead of the human maintainers doing their jobs properly.

slack-suggests does not have a sufficiently complex syntax, it can't
do what we sometimes need in the real world, for example packageA
*needs* packageB to have been built with its optional python3
dependency. (it's not just python3, there are others too)

slack-conflicts does not have a sufficiently complex syntax, it can't
do what we sometimes need in the real world, like the conflicts
between nvidia-driver and mesa+xorg-server.

A final personal opinion: our policies evolve when people ask good
questions, and this is a good question. Thank you :)

SlackBuilds-users mailing list
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Reply via email to