security/{nmap,zenmap} consolodation
Hi ohauer@ I was curious if you would be intnerested in consolidating security/zenmap into security/nmap with the options framework and deprecating security/zenmap since it continually falls pretty far behind newer versions of nmap in ports. I am fairly sure that within the next couple days I could come up with a prototype Makefile for this if you are interested or would like me to do so but I don't want to put any time into it if this will not happen. Let me know what you think. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/{nmap,zenmap} consolodation
On 2011-07-04 16:48, Jason Hellenthal wrote: Hi ohauer@ I was curious if you would be intnerested in consolidating security/zenmap into security/nmap with the options framework and deprecating security/zenmap since it continually falls pretty far behind newer versions of nmap in ports. I am fairly sure that within the next couple days I could come up with a prototype Makefile for this if you are interested or would like me to do so but I don't want to put any time into it if this will not happen. Let me know what you think. I haven't touched zenmap because I don't use a gui on any of my FreeBSD machines (my gui replacement is parameter -oN / -oG and vi ;) Thats also the reason for me to keep the ports nmap/zenmap separate. If you have patches for zenmap or perhaps want to maintain zenmap I'm fine with it. -- olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/{nmap,zenmap} consolodation
On Mon, Jul 4, 2011 at 10:48 AM, Jason Hellenthal jh...@dataix.net wrote: Hi ohauer@ I was curious if you would be intnerested in consolidating security/zenmap into security/nmap with the options framework and deprecating security/zenmap since it continually falls pretty far behind newer versions of nmap in ports. Remember that with the OPTIONS framework only one package gets generated: whatever the default OPTION is. Not everyone wants the GUI and those who want the GUI may not want to build the port from source. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/{nmap,zenmap} consolodation
On 4 Jul 2011 21:47, Eitan Adler li...@eitanadler.com wrote: On Mon, Jul 4, 2011 at 10:48 AM, Jason Hellenthal jh...@dataix.net wrote: Hi ohauer@ I was curious if you would be intnerested in consolidating security/zenmap into security/nmap with the options framework and deprecating security/zenmap since it continually falls pretty far behind newer versions of nmap in ports. Remember that with the OPTIONS framework only one package gets generated: whatever the default OPTION is. Not everyone wants the GUI and those who want the GUI may not want to build the port from source. Ok... so how about a master/slave port? That'd keep everything in sync. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/{nmap,zenmap} consolodation
On Mon, Jul 04, 2011 at 10:20:29PM +0100, Chris Rees wrote: On 4 Jul 2011 21:47, Eitan Adler li...@eitanadler.com wrote: On Mon, Jul 4, 2011 at 10:48 AM, Jason Hellenthal jh...@dataix.net wrote: Hi ohauer@ I was curious if you would be intnerested in consolidating security/zenmap into security/nmap with the options framework and deprecating security/zenmap since it continually falls pretty far behind newer versions of nmap in ports. Remember that with the OPTIONS framework only one package gets generated: whatever the default OPTION is. Not everyone wants the GUI and those who want the GUI may not want to build the port from source. Ok... so how about a master/slave port? That'd keep everything in sync. That would be perfect. I retract what I said about the options framework idea. That would take and awfulhack just to get around that and I personally would not like to see that happen. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/{nmap,zenmap} consolodation
On Mon, Jul 04, 2011 at 10:36:22PM +0200, Olli Hauer wrote: On 2011-07-04 16:48, Jason Hellenthal wrote: Hi ohauer@ I was curious if you would be intnerested in consolidating security/zenmap into security/nmap with the options framework and deprecating security/zenmap since it continually falls pretty far behind newer versions of nmap in ports. I am fairly sure that within the next couple days I could come up with a prototype Makefile for this if you are interested or would like me to do so but I don't want to put any time into it if this will not happen. Let me know what you think. I haven't touched zenmap because I don't use a gui on any of my FreeBSD machines (my gui replacement is parameter -oN / -oG and vi ;) Thats also the reason for me to keep the ports nmap/zenmap separate. Understandable. ;) If you have patches for zenmap or perhaps want to maintain zenmap I'm fine with it. Some people have mentioned a slave port. Would you mind if that happened ? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/{nmap,zenmap} consolodation
On 2011-07-04 23:20, Chris Rees wrote: On 4 Jul 2011 21:47, Eitan Adler li...@eitanadler.com wrote: On Mon, Jul 4, 2011 at 10:48 AM, Jason Hellenthal jh...@dataix.net wrote: Hi ohauer@ I was curious if you would be intnerested in consolidating security/zenmap into security/nmap with the options framework and deprecating security/zenmap since it continually falls pretty far behind newer versions of nmap in ports. Remember that with the OPTIONS framework only one package gets generated: whatever the default OPTION is. Not everyone wants the GUI and those who want the GUI may not want to build the port from source. Ok... so how about a master/slave port? That'd keep everything in sync. Hm, the only part both ports share is the sourefile ... We can try a master/slave, but I suspect it will end in many additional .ifdef/.ifndef in the nmap Makefile which makes maintenance harder. Additional both ports should keep a own pkg-plist (not a shared one). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
