Okay, I'm hoping we can achieve convergence
on packaging standards and agree on what packages
should look like and do.
However, I think we've got some problems/issues and
I thought I'd try to rehash the ones I remember. If
I've missed any, or explained them poorly,
please correct me.
1. At package install time, should we create a
global wine.conf?
View 1: No - we supply something like
wine.conf.template, and then walk
the user through using winecfg of wineconf
to get their own .winerc.
View 2: Yes. We autobuild a global wine.conf
file during the install process.
With debian, we can do this somewhat
elegantly due to debconf.
Side issues: With View 2, there is a hope that
Wine can support a true multiple user configuration.
Some of us feel that this is not worthwhile to
try to support at this time.
Perhaps we resolve this by saying that for debian,
because of debconf, we take view 2, and for RPMS,
we take view 1. I hate to diverge, but I think the
opposing views are pretty entrenched.
2. (Not yet discussed) - What packages do we provide?
Marcus provides one - Wine.
Ove provides five - libwine-dev, libwine, wine-doc, wine-utils,
and wine.
I would argue that Marcus provides too few, and that Ove
provides too many.
Remember that packages are not for *us*, they're for end users.
IMHO, end users really want one of two things:
1. Wine - to run my app
2. Winelib - to build my app
(okay, no one really wants this yet, but they're
going to if I have anything to do with it <g>).
I think splitting off the doco to save users download time
is perfectly reasonable, and won't confuse end users.
However, I think the current split into five, while I
understand the motive, is confusing to the end user.
3. Concern - winecfg dependencies
When designing winecfg, we chose Tcl/Tk, partly because
that's what TkWine used, and we were trying to expand on that,
and partly because we didn't have a clear alternative.
Initially, Martin built winecfg for distribution linked
entirely against static libraries. This meant that
winecfg created no new dependencies on new users.
However, it increased download sizes fairly signficantly.
So, the current thinking is to have winecfg linked
completely dynamically, and impose these requirements.
Maybe we need to go back to the drawing board and
reexamine this issue; perhaps some libraries could
be static, and some dynamic. I think the goal would
be to have the Wine packages work perfectly on
'stock' distributions (i.e. RH 7, Suse 7, OpenLinux 2.4, etc).
Our current thinking is that Wine will not *require*
Tcl/Tk etc, but that it will try to launch winecfg.
If that launch fails, Wine will generate a
message, and then revert to wineconf/wineinstall.
4. Whitepaper / packaging specification paper
Ove, you suggested that we should have a whitepaper
to provide potential packagers with common ground.
I think that's a great idea.
I will work on revising Marcus's packaging guide.
Then, Ove and others can beat me up, and maybe we
can make it reflect the consensus <g>.
5. Misc questions
Marcus, what is /usr/bin/winesetup in your package?
Ove, why did you rename wineinstall to wineconfig?
It seems to me that this is confusing (or at least it
would confuse me). If wineconfig is a better name for
the tool, shouldn't we change it in CVS?
I know I missed a bunch. Let me know.
Jer
