OK, I accept your decision. <br>I will maintain a list myself for the applications which I use.<br><br><div><span class="gmail_quote">On 3/2/07, <b class="gmail_sendername">Robby Workman</b> &lt;<a href="mailto:rworkman@slackbuilds.org">
rworkman@slackbuilds.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Deak, Ferenc wrote:<br><br>&gt; I know this is FAQ no 14, and I know all the technical and political issues
<br>&gt; issues of the &quot;dependecy problem&quot;, but...<br>&gt;<br>&gt; The current rule of this slackbuild project is that we can put the<br>&gt; &quot;informal&quot; list of dependencies into the README file.<br>&gt;
<br>&gt; Supposing that most of us have a full slackware install on our machines,<br>&gt; is it a very bad idea that a package lists those dependencies formally<br>&gt; which are solved by the slackbuilds project?<br>&gt; For example we can put &quot;SBODEPS=pkg1,pkg2&quot; os something similar to the
<br>&gt; .info file.<br>&gt;<br>&gt; The reason is that I would like to write a script to<br>&gt; 1. to compile an application automatically, building its sbo deps before<br>&gt; 2. I would like to write a script which checks which packages have to be
<br>&gt; rebuilt, when an other package releases a newer version. I know this<br>&gt; later is harder because I have to know that I really need a rebuild or not.<br>&gt; (when I have a newer .so lib it does not necessary need to rebuild of its
<br>&gt; dependant)<br>&gt;<br>&gt; So the first target is 1.<br>&gt;<br>&gt; If we do not want to put it to the .info the second choice is to put it to<br>&gt; the README as now,<br>&gt; but in a standard form (in a separate line by a leading token) to able to
<br>&gt; parse by grep or<br>&gt; similar tools.<br><br><br>Unless something changes upstream (as in, Pat changes his stance on<br>the automated dependency resolution issue as a whole), I can say with<br>almost 100% certainty that this functionality will never be officially
<br>supported and/or endorsed by the SlackBuilds.org project.<br><br>The goal of this project was never to provide a &quot;super-tool&quot; that<br>would find, download, compile, and install an application and its<br>dependencies.&nbsp;&nbsp;It requires enough time (from volunteer project admins)
<br>to simply test and approve submissions - trying to maintain a list of<br>dependencies, incompatibilities, flavors (and the accompanying<br>dependencies/incompatibilities with them) is just too much work for<br>very limited benefit.
<br><br>If some third party wishes to try and maintain such a list, then<br>that&#39;s fine with us.&nbsp;&nbsp;However, we will not be adding any new parts to<br>the $APP.info file format for the sole purpose of supporting some<br>
third-party dependency management.<br><br>RW<br><br>--<br><br><a href="http://slackbuilds.org">http://slackbuilds.org</a><br>_______________________________________________<br>Slackbuilds-users mailing list<br><a href="mailto:Slackbuilds-users@slackbuilds.org">
Slackbuilds-users@slackbuilds.org</a><br><a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br></blockquote></div><br>