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> <<a href="mailto:rworkman@slackbuilds.org">
rworkman@slackbuilds.org</a>> 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>> I know this is FAQ no 14, and I know all the technical and political issues
<br>> issues of the "dependecy problem", but...<br>><br>> The current rule of this slackbuild project is that we can put the<br>> "informal" list of dependencies into the README file.<br>>
<br>> Supposing that most of us have a full slackware install on our machines,<br>> is it a very bad idea that a package lists those dependencies formally<br>> which are solved by the slackbuilds project?<br>> For example we can put "SBODEPS=pkg1,pkg2" os something similar to the
<br>> .info file.<br>><br>> The reason is that I would like to write a script to<br>> 1. to compile an application automatically, building its sbo deps before<br>> 2. I would like to write a script which checks which packages have to be
<br>> rebuilt, when an other package releases a newer version. I know this<br>> later is harder because I have to know that I really need a rebuild or not.<br>> (when I have a newer .so lib it does not necessary need to rebuild of its
<br>> dependant)<br>><br>> So the first target is 1.<br>><br>> If we do not want to put it to the .info the second choice is to put it to<br>> the README as now,<br>> but in a standard form (in a separate line by a leading token) to able to
<br>> parse by grep or<br>> 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 "super-tool" that<br>would find, download, compile, and install an application and its<br>dependencies. 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's fine with us. 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>