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.
>
> 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.
>
No, do that. At least to begin with. Get some RPMS out and around, then
work on doing #2 immediately. I dunno what to do with deb. If Ove is still
interest in hacking a kick-ass debian package together then you will be able
to look at Ove's stuff to come up with an equivilant for RPMs rather than
reinvent the wheel.
>
> 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.
>
Well sort of, but Ove's situation may be better for debian. On RedHat
I would suggest the following names:
wine: All things required for running windows exes and winelib programs and
any utilities necessary for configuration (like regapi and
wineinstall and stuff) (so like Ove's wine and libwine and part of
wine-utils packages I guess)
wine-devel: All things required for developing wine applications. Also
include utilities like winebuild that are needed for winelib development
(Ove's libwine-devel I assume)
wine-doc: All kinds of wine documentation. Don't forget to use the
appropriate macro for the docdir as some RPM systems use /usr/doc while the
newest redhat has gone to /usr/share/doc to be more inline with the new
filesystem standard. However, it may be a good idea to have some of the
documentation as part of the main wine package, especially things related to
configuring wine on the system.
wine-utils: Extra utilities that aren't needed but are good to have anyway.
So I guess that makes 4 then, and in a slightly different manner than Ove.
However, Ove may have good reasons pertaining to the way Debian likes
packages to be done that dictated which files he put in the packages in
order to be accepted for official debian inclusion. RedHat doesn't really
have any set rules and thus we can do what we think is appropriate for our
project.
>
> 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.
>
Right, I will probably never have a packaged version of Wine on my system
for very long unless I am testing it or something. All my stuff comes out
of CVS. See above for me thoughts on what the packages should be named.
>
> 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.
>
You should package winecfg seperately in any case. In fact, I think you
should package it with a completely different .spec (i.e. not part of the
wine build process). It is not part of the wine sourcetree and building
more than one thing in one rpm .spec never really works out very well. See
RedHat's kernel RPM spec for an example of this, which incidently is
probably a good .spec to look at if you want to know exactly what not to do
when building an rpm. The whole specfile reaks of RedHat specific things
and seems to be more tuned for RedHat's builds on their kernel building
machine rather than make sense.
As far as dependencies go... you could provide updated versions of the
packages required so long as they won't break other stuff on the system.
Then users can just update their system a bit to get winecfg to work.
Updating their system merely involves upgrading a few rpms that can be
provided on the same webpage as the winecfg package. Send the updated specs
and whatnot to RH through bugzilla and they might even do a feature
enhancement errata or something. Of course this means a lot of extra work,
but would appear to be "The Right Thing". Although in this case it may be
easier just to staticly link with the newer version.
When upgrading libraries with proper RPM organazation it should be possible
for a user to install the updated package along with the current package.
In that case then you don't have to worry about how it will effect other
packages. Winecfg hackers can also then update the -devel package so they
develop against the new version.
Now, if it's a package that simply isn't included then by all means make a
good package of it to satisfy the dependency.
>
> 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.
>
Yes, it's a wonderful idea, should have been done long ago. It should
probably be fairly distribution/packaging-system neutral, but should include
real-world examples of the .spec file and or debian files to illustrate.
I can see Alexandre's point about not actually including the specfile, but
we definitely want to include it as part of the docs. And I still say we
should provide it in raw format with the docs in addition to mentioning it
in the docs.
>
> 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>.
>
Hell yes. Isn't that what free software development is all about :-).
>
> 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.
>
One thing I was thinking of was the issue of Wine's binary compatibility,
especially from the point of view of codeweavers. I am assuming you are
doing all of this so you can setup an environment for running the programs
that you are porting. This may be a non-issue as i think most core issues
are near-finalized. However, we may want to plan for the future and allow
multiple copies of wine/winelib to be installed. One way to do this is to
use the RPM Prefix facility. So we could allow users to specify
RPM commandline options to relocate the package from /usr to
/usr/lib/wine-20001031 and have the heirarchy under that. However, this
directly conflicts with using rpaths and instead requires some extra
trickery. To make this work you have to use environment variables to
specify which copy you actually want to use. It should be possible to setup
some scripts to do this. Check how the qt version 2 packages drops a couple
files into /etc/profile.d that set QTDIR appropriately.
You could then have a script for running winelib programs that used that
variable to set the variables relating to the library paths appropriately.
This is still a bit of a pain for the end-user, but easier than not being
able to do it at all. And actually, if you setup packages of winelib
programs with support for this built in, then it really is a total non-issue
for the end-user and all that is involved is providing the appropriate
relocation point when installing the older winelib and then using that same
relocation point in the script for the winelib program. That actually
wouldn't even involve globally setting a WINEDIR or whatever.
Or you could just do the right thing and rebuild all the winelib
applications as new versions of wine come out, but that might not be an
option in a lot of cases. I don't know because I am not familiar with how
you do your contracts or anything, but I am just providing a solution to a
problem that I forsee happening.
>
> Jer
I believe that you should probably start working on the actual specfile now
if you haven't already and maybe post it onto wine-devel so others can
actually hammer on the code a bit :-).
-Dave
