Wireshark-dev: Re: [Wireshark-dev] PortableApps Wireshark feedback
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Tue, 13 Nov 2007 20:18:54 +0100
Graeme,
first of all, thanks again for bringing the PortableApps thing to life, I think this was a good thing which now needs some more polishing and shows up some already existing problems even more clearly - so please don't take my words too seriously.
The discussion here only indicates a problem that wasn't really addressed and seems to get much worse each time someone adds a new packaging method. 

Graeme Lunt schrieb:

I am confused. Based on your own checked in changes:
http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=23431
and
http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=23433

the following files need to be changed (one change in each file):
NSIS: makefile.am, makefile.nmake, wireshark.nsi = 3 files
U3: makefile.nmake, u3util.c = 2 files
PortableApps: WiresharkPortable.ini, WiresharkPortable.nsi = 2 files

On this basis, maybe we should be more worried about the maintainability of
the NSIS packaging! :-)
Well, we had only the NSIS packaging some time before, so we had 3 places in 1 directory (not really good, but not too bad). Now we have 7 places in 3 directories (it's real ugly now IMHO and no one seemed to care). 
Do you mean in appinfo.tmpl? And this line:
Version: 0.9.6

This is the PortableApp version - not the Wireshark version - which would
have been 0.99.6 anyway.
If it is not, can you let me know which file you are referring to?

Upps, you're right, sorry for that one.
As I had updated the NSIS packaging to WinPcap 4.0.2 pretty quickly, it took me about an hour to find all places to update on the U3 and PortableApps packaging. 
Wow! I could have done it in minutes (and I had said I would).

But when?
If I would have expected that I had to change the sources, I could have done this quickly - yes. But I wasn't expecting it, so doing a distclean and a rebuild twice takes quite a while ...
As I've recently updated my NSIS to 2.32, the previously "installed" FindProcDLL.dll was gone. 
Maybe something to discuss with the NSIS people?
Hmmm, did they add the requirement of this dll to Wireshark? They seem to handle possible version conflicts by removing any third party plugin dlls.
What I meant is: Adding the requirement of the FindProcDLL.dll, won't make the maintainability of the whole build better. 
This can't be the way to go in the future!!!

I didn't think it was that bad ...

But it's getting worse every few months ;-)
... however, there is (IMHO) a much bigger problem in this area: 
We have multiple files that define what a Wireshark binary distribution
consists of. For example,
1) packaging/NSIS/wireshark.nsi
2) packaging/U3/win32/makefile.nmake
3) Makefile.nmake
(The PortableApps packaging uses the U3 list, otherwise there'd be a 4th.)

We could really do with just one location/manifest in a generic format that
lists all the files need to run Wireshark, with a mechanism to include
packaging/platform specific meta data. Then when someone wants to add an
additional file, or update a dll, then there is just one place to do it.
Maybe an XML file and some stylesheets?
Well, the WinPcap version was only one indication of the same problem as you describe it here. I was already aware of that problem gotten worse over time, e.g. at the time the U3 packaging was added, the one that checked it in said something like: "I sort of duplicated the files from the NSIS package for now, this has to sorted out later". But nothing has happended since then. And now you add another packaging that makes things a little worse again :-(
Having a meta format to describe the required files seems a good idea. However, I don't think we currently have a tool to handle XML and I don't like the idea of adding another tool. As the number of tools a newbie needs to install to generate Wireshark is already very huge IMHO. Each new tool also adds the possibility of new problems.
Maybe we can find a way to use the existing toolchain for this (e.g. like the version stuff using sed today)? 

Regards, ULFL
P.S: If there's no solution with the tools we currently have, it's obviously better to use XML with a new tool than to leave it in the way it currently is.