On 10/24/2016 02:57 PM, Christoph Willing wrote: >>----- >> > Because ffmpeg has so many options, it is a good example of the problem > to decide which to include. Some people want a mean & lean ffmpeg with > minimal options, while others want the lot. Even with a new OPTIONAL > field, which options would be included in it that would please everyone? > Each builder will probably modify to suit themselves. > > Of course everyone already has that option - to modify the .info file > with any additional fields they want. For ffmpeg I add: > ENVOPTS="LAME=yes X264=yes CELT=yes ..." > My build tool finds ENVOPTS and exports each of the variables found, > triggering the desired options already supplied in the ffmpeg.SlackBuild > file. > > However the maintainer can't know what options I want. They could put > all the possible options in a new OPTIONAL field but perhaps I don't > want _all_ of them; just some of them. Then I, the builder, would still > have to make the changes to suit my own needs/desires, so what has been > gained? > > Anyway, whatever the mechanism is used, its up to the various build > tools to actually support it. Maybe one of the public build tools will > introduce something of their own just to see if it catches on. > > chris > <start of RANT>
Reading through this threads commentary, I find everyone is going in circles. The above is one of the smarter responses. Whether it's ffmpeg, qemu or whatever there are just too many optional choices. Debian et al., Redhat, Gentoo, etc all try to automate the software installation process with mixed results. [ Day1: Gentoo User: "Yo Ed, check out "emerge world"! How cool is that?" Day 2: Me: "Say, is your server still up?" Gentoo: "In a bit. I decided to reinstall from scratch." Me: "What happened?" Gentoo: "Oh, just decided to start over clean." Me: (Sigh). ] 20+ yrs ago I choose Slackware because WE DON"T DO THAT. SBo, has a difficult task: It's one thing to test for all REQUIRED deps so that a package compiles, it's quite another to sift though the various build systems (Documentation? Read the source, Luke.) to find various optional deps. I've run into 1. Autodetected at compile time 2. Autodetected at run time 3. Configured during compile time but not autodetected There can be SCORES of these in various combinations, even after adjusting for a full Slackware installation. Some even have x86_64 vs x86 choices. This is just nuts from an automation standpoint. As Chris states above, not everyone will want the same options. Thus there is no way to keep everyone happy. As a maintainer, I volunteer my time on SBo and LQ to "pay forward" for all those years a sucked for free off the Slackware teat. I also purchase the odd item at the Slackware Store. That is pretty much my total skill set available. I personally use most of the SBo scripts I maintain. I simply do not have the time, the skill, or the hardware to sift and test all OPTIONAL deps. Hell, I don't even work in the Computer software/hardware/MIS/IT industry. As far as I know, no one involved in SBo gets paid. So, I vote NO on additional bloat added to SBo. Additional functions should have a damn good reason to exist, simple to implement, easy to maintain, and transparent. For those who disagree I think I should devote my time to making their lives easier, I suggest you fork the repo and do whatever the hell you want. Just stop nagging me for weird-ass option most people don't use. I have yet to nag an SBo maintainer of a scrip I use to add optional support that may only be useful to me. Now that said, I will be adding BRIDGE_HELPER_SETUID to qemu, for example, because 1. I didn't now about it 2. it's useful to the entire user base I am not opposed to having the community emailing me with useful feature additions or true bug reports. I just thinks it is up to the individual user to add their own fringe-case options. -Ed <end of RANT>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/