I say leave it as is.  Although I like the idea of dependency checks it scares me if there is an either or when you have neither installed.  <br><br>Sent via my mobile handheld communications device<br><br>----- Reply message -----<br>From: "Ben Mendis" <dragonwisard@gmail.com><br>To: "SlackBuilds.org Users List" <slackbuilds-users@slackbuilds.org><br>Subject: [Slackbuilds-users] requirements in README files<br>Date: Mon, Jul 9, 2012 20:45<br><br><br>On Mon, Jul 9, 2012 at 9:00 PM, David Spencer <<br>baildon.research@googlemail.com> wrote:<br><br>><br>> Yeah, long chains of indirect dependencies are a pain.  They'd be even<br>> more of a pain if our flexible source-based locally-managed dependency<br>> resolution was more rigid.  There's nothing better than noticing that<br>> a tricky dependency turns out to be optional, contrary to expectations<br>> :-)<br>><br>><br>Right! In no way am I asking for more rigidity or even for an automated<br>solution. What I would find nice, however, is a standard syntax for<br>indicating the names of direct dependencies (whether mandatory or optional)<br>so that I can write tools to resolve a rough outline of a dependency graph<br>and at least get some idea of which packages I *might* need or want and<br>approximately what order they should be installed in. Even something<br>as noncommittal as that is currently a challenge to automate and requires a<br>lot of manual foot work.<br><br>Isn't the point of computing to automate the mundane tasks so that we can<br>focus our minds and efforts on the truly interesting problems? Why are<br>people on this list so vehemently opposed to the idea of OPTIONAL metadata?<br>It wouldn't have any impact on your current way of doing things, but it<br>might be of value to people who aren't quite as masochistic.<br><br>I love Slackware, and I love the way Slackware's package management works.<br>That said, I'm not blind to the fact that it has trade-offs and<br>shortcomings. Proposals like this are a very non-intrusive way to<br>experiment with potential improvements without forcing work on anyone or<br>taking away any functionality or flexibility. You can love and respect<br>something, but still want to improve it. Package and dependency management<br>are clearly not "solved" problems, and while Slackware is better than most,<br>it's not perfect.<br>