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