ferenc.deak at gmail.com
Fri Mar 2 20:00:41 UTC 2007
OK, I accept your decision.
I will maintain a list myself for the applications which I use.
On 3/2/07, Robby Workman <rworkman at slackbuilds.org> wrote:
> Deak, Ferenc wrote:
> > I know this is FAQ no 14, and I know all the technical and political
> > issues of the "dependecy problem", but...
> > The current rule of this slackbuild project is that we can put the
> > "informal" list of dependencies into the README file.
> > Supposing that most of us have a full slackware install on our machines,
> > is it a very bad idea that a package lists those dependencies formally
> > which are solved by the slackbuilds project?
> > For example we can put "SBODEPS=pkg1,pkg2" os something similar to the
> > .info file.
> > The reason is that I would like to write a script to
> > 1. to compile an application automatically, building its sbo deps before
> > 2. I would like to write a script which checks which packages have to be
> > rebuilt, when an other package releases a newer version. I know this
> > later is harder because I have to know that I really need a rebuild or
> > (when I have a newer .so lib it does not necessary need to rebuild of
> > dependant)
> > So the first target is 1.
> > If we do not want to put it to the .info the second choice is to put it
> > the README as now,
> > but in a standard form (in a separate line by a leading token) to able
> > parse by grep or
> > similar tools.
> Unless something changes upstream (as in, Pat changes his stance on
> the automated dependency resolution issue as a whole), I can say with
> almost 100% certainty that this functionality will never be officially
> supported and/or endorsed by the SlackBuilds.org project.
> The goal of this project was never to provide a "super-tool" that
> would find, download, compile, and install an application and its
> dependencies. It requires enough time (from volunteer project admins)
> to simply test and approve submissions - trying to maintain a list of
> dependencies, incompatibilities, flavors (and the accompanying
> dependencies/incompatibilities with them) is just too much work for
> very limited benefit.
> If some third party wishes to try and maintain such a list, then
> that's fine with us. However, we will not be adding any new parts to
> the $APP.info file format for the sole purpose of supporting some
> third-party dependency management.
> Slackbuilds-users mailing list
> Slackbuilds-users at slackbuilds.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Slackbuilds-users