[pkg-wine-party] [wine] 03/08: Create winepath link and manpage.

[Jens Reyer]

Sorry for the delayed answer. Replying to both previous mails in this
thread.

On 02/28/2016 07:59 PM, Michael Gilbert wrote:
> On Sun, Feb 28, 2016 at 10:56 AM, Jens Reyer wrote:
>> Speaking of the tools:
>>
>> Do we give up on 32-/64bit co-installability of the tools permanently? I
>> saw nobody complaining, neither after their dependencies made them
>> not-coinstallable, nor since they officially conflict now.
>
> My opinion is yes.
>
>> If yes, I propose to provide symlinks in path for all the tools now in
>> /usr/lib/wineVERSION/ (wmc, wrc, winedump, winebuild and winemaker). 5
>> additional links in /usr/bin seem fair to me for an optional package
>> that needs to be installed on purpose.
>
> That seems fine.
>
>> We may also merge the wine[32|64]VERSION-tools.
>
> No, we should leave it possible for the user to choose which bitness
they want.

With multiarch:foreign that still would be possible (if the dependencies
gcc and perl didn't prevent it). However, on updates some package
manager might switch to the native version, unless there's some apt
pinning. So ok.



On 02/28/2016 08:03 PM, Michael Gilbert wrote:
> Some of the tools are arch-indep scripts.  We should probably split
> into wine-gcc[arch] and wine-tools[any].

I only found  the scripts winemaker and winepath. The following are
binaries: winebuild, winedump, wmc and wrc.


> On your 1.8 updates, keeping wine and wine-development totally in sync
> I think isn't totally desired.  My intent is for things to bake in
> wine-development, and then get synced back up at stable release time.

Which stable release do you refer to? Debian Stretch, minor Wine release
(1.8.2), or major Wine (2.0). I assume major Wine, which might either
happen shortly before the Debian freeze, or too late for stretch.

I think a sync shortly before the Debian freeze might result in bugs
popping up, that weren't noticed in wine-development (mainly because
there's another, but much larger user basis, for wine), without giving
us the time to fix them.

Not syncing would get us the packaging mainly from December 2015 in
Stretch (release early 2017).


> The way things are going now, we end up dealing with bug fixes twice.

An imo big part of the syncs is already done to deal with bugs, although
they are not reported in the bts. Of course a fix can introduce a new bug.

My main motivation is to prevent a situation as in jessie, where wine
was released with at least one bug that was fixed in wine-development
already for a long time.

Further if we expose the packaging to both wine and wine-development
users, we have a bigger chance to notice bugs, and release the next
Debian stable with both a better wine and wine-development.

Finally maintaining and supporting imo is much easier, if the packaging
is quite identical.


My favorite solution would be a common shared packaging branch with all
Debian changes, some conditionally only for wine or wine-development
(similar as proposed in #761574, but I had some new ideas since then).
wine releases could still be done with a lower frequency.
This would pose a higher initial workload, but imo pay off in the long run.


Anyway, I see your use of "totally" and I already had postponed some
syncs. So I will be much more conservative on that from now on, trying
to distinguish between "new feature" and "bug fix". Then I'll propose my
intended sync-changes first. I'll leave at least the embedded code
copies and regenerate things untouched.

But e.g. if there aren't any further changes the next few weeks, I'd
propose to merge the output changes (scripts/wine, scripts/wineserver
and README.Debian).


Thanks for your feedback!

Greets
jre