On Tue, Oct 31, 2000 at 12:51:20PM -0600, Jeremy White wrote:
> 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.
>
>
> 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.
Err, why ?
IMO Debian builds packages the way they are the most usable,
and this is by making sure that every separate part of a certain program
remains separate.
That way you have a very customized way of getting exactly what you want,
instead of getting tons of things you don't really need.
What so difficult about doing an apt-get install wine, and getting,
say, libwine and wine this way ?
OK, maybe one could talk about an additional dependency on wine-utils here,
after all wine is not intended for server systems where the number of
installed packages is an issue.
But on the other hand your favourite notebook perhaps doesn't have enough
space to really be happy about the fact that the utils get installed
forcibly...
> 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.
Maybe a relatively good compromise for the time being, yes.
> 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>.
Good !
> 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?
Err, yes, consistency ought to be somewhat desired, I guess ;-\
> I know I missed a bunch. Let me know.
Same here. No idea what else to discuss.
Andreas Mohr
