Actually, a wine and wine-devel would be good, to match what we're doing with .rpm files. Reduces confusion. While you're at it, it would be nice to host them also on SF, so we have a one place that holds all the wine packages.
-- Dimi.
Well, I am condensing it down. Here's what I think we should move towards with packaging:
wine : depends on libwine, contains the binaries for running windows programs libwine : contains everything needed to run windows applications libwine-dev : contains the files needed to compile windows applications with winelib
My reason for splitting off libwine and wine is that libwine can be installed without wine and could someday be used to launch a program that has been ported with winelib, without having to have wine proper in it.
I imagine someday I'll take an open source Windows program like eMule, set it up to compile with winelib, and have it turned into a Debian package. This way one could apt-get install emule and then have it depend on and install libwine, but not wine.
The reason for using libwine rather than winelib is to comply with Debian standards.
Thoughts?