Re: [Slackbuilds-users] What about slack-{required, suggests} files?
Caveat: this rant doesn't bring much added value to David's answer to the OP. Still, here it is, as maybe not every submitter is aware of how the information about deps is used by some tools. Le 10/03/2018 à 20:23, B Watson a écrit : > On 3/10/18, David Spencer wrote: > >> 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. > > Also, tools that use slack-required are probably going to get confused > by the fact that our REQUIRES doesn't list core Slackware packages, > only SBo ones. the slapt-get tool reads the metada in PACKAGES.TXT like this one for espeak: PACKAGE NAME: espeak-1.48.04-x86_64-4slint.txz PACKAGE LOCATION: ./slint PACKAGE SIZE (compressed): 1096 K PACKAGE SIZE (uncompressed): 4384 K PACKAGE REQUIRED: aaa_elflibs|alsa-lib,aaa_elflibs|gcc,aaa_elflibs|gcc-g++,portaudio PACKAGE CONFLICTS: PACKAGE SUGGESTS: PACKAGE DESCRIPTION: espeak: eSpeak (a compact open source software speech synthesizer) espeak: espeak: eSpeak produces good quality English speech. It uses a different espeak: synthesis method from other open source text to speech (TTS) engines, espeak: and sounds quite different. It's perhaps not as natural or smooth, espeak: but some find the articulation clearer and easier to listen to for espeak: long periods. It can run as a command line program to speak text from espeak: a file or from stdin. espeak: espeak: HomePage:http://espeak.sourceforge.net/ espeak: In this case PACKAGE REQUIRED lists core Slackware packages as deps, as they are written by a script that reads the .dep files, themselves written using George Vlahavas' depfinder, then edited manually when necessary. Of course the list of deps depends on the context of the build. It recently failed to start mate-terminal because I had built it with webkit2gtk installed, but since removed. About using the deps to build (not install) a package, the information is already included in SLACKBUILD.TXT, e.g. this one: https://slackbuilds.org/slackbuilds/14.2/SLACKBUILDS.TXT Let's take again the espeak example. SLACKBUILD NAME: espeak SLACKBUILD LOCATION: ./accessibility/espeak SLACKBUILD FILES: README espeak.1 espeak.SlackBuild espeak.info makefile.patch slack-desc SLACKBUILD VERSION: 1.48.04 SLACKBUILD DOWNLOAD: http://downloads.sourceforge.net/espeak/espeak-1.48.04-source.zip SLACKBUILD DOWNLOAD_x86_64: SLACKBUILD MD5SUM: cadd7482eaafe9239546bdc09fa244c3 SLACKBUILD MD5SUM_x86_64: SLACKBUILD REQUIRES: portaudio SLACKBUILD SHORT DESCRIPTION: espeak (a compact open source software speech synthesizer) These lines are copied from espeak.info: https://slackbuilds.org/slackbuilds/14.2/accessibility/espeak/espeak.info Here portaudio is rightly listed here as the only needed dependency beyond a full Slackware installation. As an aside, slapt-src, used by Slint, Salix and other Slackware derivatives use this file to manage the dependencies. So, having a separate slack-required file in a submission would be redundant at least for this use case IMHO. I didn't check that slapt-src builds the deps in the right order as the one give by sqg, but if it could using a similar algorithm. Have a good day, Didier ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] What about slack-{required, suggests} files?
On 3/10/18, David Spencer wrote: > 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. Also, tools that use slack-required are probably going to get confused by the fact that our REQUIRES doesn't list core Slackware packages, only SBo ones. > 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 :) Same deal with this, it would have to be able to list core Slack packages. Example would be texlive for 14.2 (conflicts with tetex). The idea about separate variables for build-time vs. runtime deps is almost appealing to me. If "foo" is a build dep that can be removed afterward, and "bar" and "baz" are runtime deps: REQUIRES="foo bar baz" BUILDREQ="foo" ...meaning there's some redundancy (foo is listed in both places), but it'd be backwards compatible with existing tools and workflows. To start out with, some kind SBo admin would write a script that adds a BUILDREQ="" line to every .info file, and maintainers could fill them in piecemeal. ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] What about slack-{required, suggests} files?
On 03/10/2018 10:50 AM, Andrew wrote: > I think we should have MAKEDEP and RUNDEP lines in info file for listing > build-time and runtime dependencies there. No need to complicate things, we're only concerned with what's required to build a package. Anything that can be removed later should already be noted in the README. > Also, can we add SHA256SUM to .info file for slackers with paranoia? ;-) The sums are not used for security, we have no control over upstream sources anyway. It's just there so end users can verify they're using the same source files that the script was tested against. -- Erik signature.asc Description: OpenPGP digital signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] What about slack-{required, suggests} files?
On 03/10/2018 09:50 AM, Andrew wrote: > Also, can we add SHA256SUM to .info file for slackers with paranoia? ;-) > > -- > Andrew +1 I wouldn't call it paranoia, just peace of mind. -- Brenton Earl ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] What about slack-{required, suggests} files?
On March 10, 2018 3:37:56 PM UTC, David Spencer wrote: > >*Personal opinions* > >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 :) > I think we should have MAKEDEP and RUNDEP lines in info file for listing build-time and runtime dependencies there. Also, can we add SHA256SUM to .info file for slackers with paranoia? ;-) >A final personal opinion: our policies evolve when people ask good >questions, and this is a good question. Thank you :) > >Cheers >-D. >___ >SlackBuilds-users mailing list >SlackBuilds-users@slackbuilds.org >https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >FAQ - https://slackbuilds.org/faq/ -- Andrew ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] What about slack-{required, suggests} files?
> 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 :) Cheers -D. ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
