[Ulf Lamping <ulf.lamping@xxxxxx>]

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.