[Slackbuilds-users] requirements in README files

[mr.chew.baka@gmail.com]

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" <dragonwisard at gmail.com>
To: "SlackBuilds.org Users List" <slackbuilds-users at 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.research at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20120711/0b281e42/attachment-0001.html>