Martin Pilka wrote:
> > Unfortunately, I guess rpms don't have such a system, so the decision of
> > whether to make the package configure things interactively or not will be
> > up to you non-debian people. Debian empowers users with choice...
>
> well, now i see there is still some space for RPM package system
> improvements...but i'm not going to improve it :-)
>
"Improving" RPM to allow user interactions is well beyond the design goals of
RPM. I suggest that you specifically do not add any user interaction to the
pre/post install or uninstall scripts of an RPM. It is not designed to do
that. However I also suggest that you provide a way for the user to configure
the package after it has been installed. Unfortunately there is not really a
specific system like debconf for RedHat unless you count Linuxconf, which may
be the nearest equivilant.
Be sure to mark config files with %config. You can either choose to replace
%config, or not replace %config(noreplace). If you choose noreplace and a
newer wine requires changes to the config file to work properly, then the
installation will be broken. If you choose the default it may replace the
config file, but will back it up as a .rpmsave. The user can then merge the
changes after the install, or try to continue with the new default config.
>
> > > * do not support multiuser configuration YET
> >
> > We can support it. I've chosen a reasonable path - use tools/wineinstall,
> > which has some basic multiuser support already. If we want to support
> > multiuser better, we'd just improve wineinstall a bit... the multiuser
> > aspect is thus up to the official Wine development effort, not up to the
> > packagers.
>
> i know. some patches to wine are required in order to support multiuser
> properly. if that patches could be done in sensible time horizont, then
> there's no reason to not support multiuser. but they are not done now.
>
Actually no, I don't believe so at all, I think Ove has taken care of this for
his Debian packages. Besides, the kind of changes you might need to make are
simple anyway. I would still say maybe get something out without multiuser
configurations so that we can collectively hack on it rather than discuss it.
Even if it has serious problems at first, it's easier to just go implement it
and fix bugs later than take 2 weeks discussing it which is what has been going
on. Just make sure you don't officially release it until it has been hacked on
by a few wine developers. I'd personally like to take a look at it myself
before it gets officially released.
Unfortunately, it would be sort of hard to collectively hack on it unless
Alexandre wants to put it in CVS. Many other projects have an RPM .spec and
debian files in them as shipped, especially all of the GNOME stuff, so it would
not be out of line (and in fact would be beneficial) to have these in CVS.
Distributions can still easily change the build process to suit their own
needs, but at least we would be providing something to start with.
Unfortunately, I think there were several very loud voices against this, which
I cannot understand, but I guess they had their reasons. Personally I feel
Ove's debian building stuff should go into the tree as well as an rpm .spec
file.
[snip tcl stuff]
-Dave
