Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[costamagnagianfra...@yahoo.it]

Hi Javier,

thanks for your hint!

That was my first thoght, I'm upstream developer and DM of ettercap and we 
already install in sbin some of the binaries.

The problem is:
what does it happen when the user have both amap installed on the system and 
runs "amap" from the bash?

This might be highly confusing for the end user, and needs to force the path to 
both .desktop files (if they provide.  them)

Thanks to all for your suggestions, I think I'll rename the binary in amap-thc, 
 avoiding this kind of troubles (and maybe also moving in /sbin).

I need to prior check how many packages needs it and how they run it, bt seems 
the most trivial task to do.

I'm on smartphone, I'll answer to everybody asap, I would like to avoid top 
posting.
(I answered to this first since I'm pretty sure having two different binaries 
with the same filename on the PATH can lead to confusion, but I might be wrong 
somewhere)

Thanks for clarifying

Gianfranco
Sent from Yahoo Mail on Android

Re: Bug#753704: Aw: Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[costamagnagianfra...@yahoo.it]

Hi Steffen and all,

today while talking with a backbox project administrator I discovered that 
popular tools such as openvas directly calls the amap binary.

I never talked with them, but I don't think it is feasible to ask to every 
security tool provider to patch their code for the only debian benefit.

I think I'm then changing again my opinion: the conflict field might be the 
only proper way to be sure such popular tools (not packaged in debian and some 
of them not even free) continue to work.

Is this one a good reason for a conflict?

Thanks for reading,

Gianfranco, who really don't want this kind of flame wars in such a beautiful 
project as debian.

Sent from Yahoo Mail on Android