On 07/23/2015 04:29 PM, Nathan Schulte wrote:
On 07/23/2015 05:23 PM, Kyle Auble wrote:
Sorry for the goofy formatting. One day Thunderbird doesn't wrap anything for me, the next it's cutting my lines short. I'm resending my message, hopefully with better formatting this time.
As a fellow Icedove user, I can say that you're not the only one who runs up against this. It's especially hairy for me around re-wrapping quoted content; I think I just don't understand how it works.
I think that sometimes the packagers or developers change default settings between releases; I used to have that all the time with Firefox on Ubuntu. Apparently by default, the current Jessie version of Icedove wraps plain-text emails at 72 characters once you send them, but automatically unwraps them if you read them. You have to go to the config editor if you want to change that.
If I understand everything, I think the main reason the wine team still bothers with a stable release is for distros like Debian Stable or Redhat.
Does Wine treat Stable this way? In that it receives bugfixes/security updates (from Development, mainline) that are applicable to making it more stable/secure? From the release log, it looks like Stable is basically dead; the last release was well over a year ago.
The impression I get is that the wine project itself treats stable a little differently. Unless someone finds an egregious security issue in wine itself, it seems like the consensus is to keep wine-stable as inert as possible and let packagers apply their own minor patches on top.
It could be because so many features are still being improved, and there's still an expectation that the development release is more likely to work for your program anyway. Also, since wine works with so many other components on the system, it might be hard to assign blame to wine or the environment alone in a lot of cases. In that situation, it kind of makes sense to delegate minor, post-release fixes to the distros.
I wonder though why the maintainers went with a separate wine-development package instead of just pointing the wine package in testing & unstable to the development release, then offering that to stable through Backports.
We can always loop them in and ask: pkg-wine-party@lists.alioth.debian.org
It seems like the packaging in Debian of both Wine Stable and Wine Development as different "packages" in their own right was the wrong choice.
So I looked into it a little more, and it's arguably not so much a choice as the natural result of an improvement to the packaging on Debian. Apparently, there was traditionally a wine-unstable package in testing & unstable, it would conflict with an install of stable wine, and its packaging code is separate from the stable wine package's. The Debian packagers decided in the past year or so to change the name of wine-unstable to wine-development. At the same time though, someone put in a lot of work and managed to make the two packages capable of coinstallation via update-alternatives. This bug report gives a pretty good overview: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758291
I guess after doing that, they figured, "Why not offer both packages for Jessie? They don't conflict." I'm still going to ask on the mail-list about possibly having a Backports version though (plus I have some other questions related to multi-arch). While the difference between wine-development and wine is a little confusing at first, I don't think that's the real problem. In my mind, putting wine-development in the stable repo is self-defeating; you lose most of a development branch's value if it doesn't track upstream closely, and wine-development on Jessie is still stuck in last October.
- Kyle