Taras,
On Fri, Feb 10, 2012 at 11:06 AM, Taras <ox...@oxdef.info> wrote:
> Andres,
>
>
>
>>> Especially those dependencies which
>>> can't be installed on distro native way (apt/yum/...).
>>
>>
>> Maybe the solution is to invest in creating an deb package for the
>> missing dependencies?
>
> Yes, it is one way and it can be right.
Ok, then lets do that :)
/ignoring the rest of your email ;) just kidding, read inline:
>
>>> Yes, I know that there are a lot of really useful Python 3rd party
>>> modules but
>>> I have a lot of life examples when people said "Hmm, I don't want to
>>> install such big number dependencies and especially not from official
>>> repository to run this scanner".
>>>
>>> What do you think about it?
>>
>>
>> We're always going to have people that think that *something* is
>> wrong, sadly, that group is much bigger than the group that sees and
>> issue and tries to fix it.
>
> Ok, I understand...
> ...
>
>> Some bad things I see in our installation process is that our code
>> is focused on guiding the users of Debian based distributions; which I
>> see as incomplete and useless for people running the installation in
>> RedHat/Fedora based distributions. Maybe there is an effort to be made
>> there? (detect distribution and show dependencies and commands
>> accordingly)
>
> Imho, it will be better to show only absent Python module names
Aren't we doing just that? We only show the missing packages that
are not found by dependencyCheck.py
> and
> recommends
> to read install.txt where we will write instructions for popular systems and
> distros.
INSTALL file is not a bad idea, it might "duplicate code" with
dependencyCheck.py , but sounds good to me.
>
>> In the future I see the amount of dependencies slowly growing once
>> again, for example, we'll need *some library* to support javascript
>> web applications, and that library will have other dependencies too.
>
> Dependencies which have dependencies...recursion sounds like recursion! :)
>
>> Also, one question, what do you mean by "hard dependencies" ? Do
>> you want to move some to "optional" ?
>
> If number of dependencies will grown we will need to separate them to
> e.g. core, plugins and optional
>
> * core dependencies are required
Agreed, and we're already using this concept
> * plugin dependencies are required only if those plugins are enabled
I see this as an annoyance to the user. He has the feeling that "he
got it to work" and when he enables plugin X the UI says: "Please
install XYZ module for enabling this plugin". I would rather have them
2 more minutes during installation :)
> * optional are optional :)
I like the optional, we're already doing this for console/gui . If you
run w3af_console the dependencies are different than the ones for
w3af_gui . Which makes sense since some guys don't ever run w3af in a
GUI.
To sum up, if we add some efforts to make sure that all dependencies
are in the Top3 linux distributions and the install documentation is
clear for the rest, can we say we've done our jobs well? :)
Regards,
>
>
> --
> Taras
> http://oxdef.info
--
Andrés Riancho
Director of Web Security at Rapid7 LLC
Founder at Bonsai Information Security
Project Leader at w3af
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
