>
> Perfect, I had recommended allowing wine to be relocated earlier but no one
> seemed to really like the idea-- although you seemed to pick up on it or
> were simply thinking the same thing. I question your version numbers
> though. IIRC RPM Release is really for the release of the package, not the
> release of the program. I would think wine-0.20001108-{RELEASE} would be
> more appropriate. The release number should generally be < 1 for internal
> test versions (like 0.1, 0.2) and 1 for the release and then > 1 for
> bugfixes. Again, use releases like 1.1, 1.2 for internal test versions
> before going to a release 2 bugfix. Looking at Red Hat's RPM's, most of
> them follow this convention. After all, wine's "version number" is really
> 20001108. Please let's not have Wine 2000 release 1108, it's bad enough
> Microsoft started bastardizing version numbers like that. :-)
Yeah, I keep waffling on what I'm going to call it. Because
you expressed an opinion, I'll switch to your suggestion.
>
>
> One other thing. Why /opt/wine ? IIRC RedHat's standard would be
> /usr/lib/wine (rpm -ql netscape-common ; rpm -ql qt for examples) although
> on most other unices/distros I think you would be correct. Of course since
> you made it relocatable the user does have that choice.
The latest rev of FHS (2.1) now specifies the use of /opt as the
way and the truth and the light for add on packages.
Also happens to fit my religious bent (heresey to some, I know),
but I really like having apps package themselves into nice
tidy, segregated, rm -rf 'able spaces.
>
> Looking forward to seeing these RPMs get released, it sounds like you have
> spent a lot of time pondering packaging issues and that these will finally
> solve the problem of "Wine sucks, I can't get it to work." If you have not
> spent some time with newbies in #WineHQ you are really missing out :-).
Yeah, that's our hope. We're really hoping to show off a 'preview'
of 1.0 at Comdex; I think Wine is really becoming amazing, and I'd like
to show it off well.
Jer
