[website] Update Debian downloads info

[Kyle Auble]

On 07/23/2015 11:14 AM, Nathan Schulte wrote:
> On 07/23/2015 10:02 AM, Rosanne DiMesio wrote:
>> Now, the problem with what you changed it to is that it now points to 
>> the page for Debian Jessie (stable), which has outdated packages, and 
>> doesn't show the packages for Stretch (testing) or Sid (unstable).  
>> My patch linked to 
>> https://packages.debian.org/search?keywords=wine-development because 
>> the search results produce links to all three, which I think is 
>> easiest for users.
> What's the difference between the Stable and the Development releases 
> of Wine?  Given this thread of discussion, it seems the Wine team 
> expects users to be using the Development release, not the Stable 
> release.  If that's the case, why even bother with Stable?  Perhaps 
> this is just a terminology thing; should Debian's wine package be 
> packaging the Development release?
I've migrated to Debian Stable within the past year (still think Ubuntu's
great, just a minimalist that wanted to wander a bit upstream). 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. The slower-moving 
distros
put a much heavier emphasis on testing; at the end of the day, they would
rather package a version of wine that they can certify works ok, rather 
than
one that works great in isolation but causes Gnome or dbus to explode.

On 07/23/2015 10:02 AM, Rosanne DiMesio wrote:
> On Thu, 23 Jul 2015 09:10:42 -0500
> Jeremy Newman <jnewman at codeweavers.com> wrote:
>> I misunderstood the package. I thought it was just a meta package to
>> install required development libs, like build-essential.
> I understand why you thought that. It's the very reason I could never 
> find the packages by googling "Debian wine," and probably the main 
> reason Debian users can't find them either.
I've actually been using the Debian package site a lot recently, and I was
under a similar impression as Jeremy. I kept seeing wine-development, but I
figured it contained headers (like most of the -dev packages) for compiling
against libwine or something.

On Thu, Jul 23, 2015 at 12:17 PM, Rosanne DiMesio 
<dimesio at earthlink.net> wrote:
> On Thu, 23 Jul 2015 10:14:38 -0500
> Jeremy Newman<jnewman at codeweavers.com>  wrote:
>> This is the root of the issue. How do Debian Stable users get the latest
>> version of Wine that is built specifically for them?
> AFAICT, they don't. Debian seems to only build the latest version for testing and unstable.
Rosanne's right about the Debian repo, which means if you want to test the
freshest wine on Debian Stable, you or someone else has to build it for 
you.
Sure enough, that's exactly what I've been trying to figure out in my 
free time
(and redo related pages on the wiki in the process). If you use chroot 
or LXC,
it's tedious but pretty straight forward, but I'm trying to figure out
precisely which wine dependencies still aren't multi-arch compatible.

IIUC, the funny thing about Debian is when they simultaneously took 
their leap
of faith from ia32-libs and resisted the RPM "heresy" of just letting 
i386 and
amd64 packages mingle freely, they made it *really* tricky to do things 
like
build WoW64-wine without a chroot. However, the second all of wine's
build-dependencies become multi-arch compatible, it *should* become very 
easy.
In the long run, I think if we could go upstream and sort out architecture
issues in wine's dependencies, that would give much bigger rewards.

Having a package of the development release definitely doesn't hurt 
though. One
immediate way it helps is you can use apt-get build-dep without 
surprises. For
example, the wine package on Jessie was still built with libgstreamer-0.10
libraries (which throw an error when you attempt a multi-arch build), 
but since
then, the Debian packagers flirted with libgstreamer-1.0, then decided 
to drop
it until it becomes more mature. 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.