Packaging Questions, New Debian Package, Packagers Guide

[Mike Hearn]

On Tue, 23 Nov 2004 19:14:00 +0100, Francois Gouget wrote:
> Having lots of packages is the Debian way. So I see nothing wrong with 
> having wine, libwine, libwine-dev, wine-doc, libwine-alsa, libwine-arts, 
> libwine-capi, libwine-cil, libwine-jack, libwine-nas, libwine-twain.

Well, it may be the Debian way but it's not the Wine way.

I'm not saying this just to be pedantic, the fact that distros like Debian
creatively ignore the way upstream is packaged caused me big problems
when I wrote the IE installer script way back in January (which still gets
~300 hits a day). I assumed that if you had Wine installed, you'd have
things like wineboot and regedit installed. These are shipped as part of
Wine after all. But they weren't, Debian had classified them as optional
utilities and my script broke. Gentoo had similar problems. I had to add
in lots of hacks to make sure all the programs I used were there, and
print out different messages for each distro giving the package name
needed.

It's not just my script. Wine and Windows programs sometimes assume these
applets are present too (eg notepad, wineboot, regedit, regsvr32).

The packaging on Red Hat/SuSE/Mandrake etc didn't have this problem
because they mostly followed upstream conventions.

If this way of splitting everything up really is better we should split
the Wine tarballs up into separate packages too. If it isn't then Debian
should follow the upstream conventions, it would save people a lot of
hassle debugging incomplete installs because some program tried to invoke
regedit or notepad and it wasn't there.

> To those surprised by the -(alsa,arts,...) packages, this
> matches the
> xmms-(alsa,arts,...) packages. So there's nothing exceptional here.

But why are they separate? What gain does this have? They're only loaded
on demand if the user wants them anyway, having the drivers installed
doesn't mean you actually have to have arts/alsa/nas installed.

> Also the wine-util package contains tools that I think belong to
> libwine-dev, especially winedbg, winedump and winemaker.

winedbg for one is invoked by Wine directly when it crashes, I think it
makes sense for it always to be present so useful remote debugging can
occur.

thanks -mike