https://bugs.winehq.org/show_bug.cgi?id=39859
Bug ID: 39859 Summary: WineHQ packages for wine-gecko and wine-mono Product: Packaging Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: wine-packages Assignee: wine-bugs@winehq.org Reporter: dimesio@earthlink.net CC: michael@fds-team.de, sebastian@fds-team.de Distribution: ---
Most users of the distros we now package for are accustomed to installing wine-gecko and wine-mono from packages. We should provide them.
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #1 from Sebastian Lackner sebastian@fds-team.de --- Is there any benefit compared to using Wines internal downloader? As I've seen just yesterday, http://wiki.winehq.org/Ubuntu says:
"""--WineHQ does not at present package wine-gecko or wine-mono. Follow the instructions on the Gecko and Mono wiki pages to install them manually."""
This is misleading, because Wine will attempt to download them on prefix creation or update, so usually no manual steps are required by the user.
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #2 from Rosanne DiMesio dimesio@earthlink.net ---
This is misleading, because Wine will attempt to download them on prefix creation or update, so usually no manual steps are required by the user.
Downloads can fail due to networking problems, and inexperienced users sometimes panic when they see the download and cancel it because they're afraid of malware. The result is a broken wineprefix and possibly an invalid bug report.
Re-downloading gecko and mono on every wineprefix creation is also a waste of bandwidth, and that's a very real concern for users subject to bandwidth caps from their ISP. I recently had to help a forum user who canceled the download for that very reason.
Installing gecko and mono locally has long been recommended to avoid those problems, and yes, users can do it manually, but it's not the most user-friendly process.
https://bugs.winehq.org/show_bug.cgi?id=39859
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #3 from Vincent Povirk madewokherd@gmail.com --- Even if you understand the dialogs and always go through with them, the download process halts prefix creation indefinitely, and if you're not paying attention Wine can time out and start the program before the prefix has been fully created.
That's an issue that may be worth addressing separately, but installing packages for gecko and mono would prevent that situation.
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #4 from Austin English austinenglish@gmail.com --- (In reply to Rosanne DiMesio from comment #2)
Re-downloading gecko and mono on every wineprefix creation is also a waste of bandwidth, and that's a very real concern for users subject to bandwidth caps from their ISP. I recently had to help a forum user who canceled the download for that very reason.
The installers are cached now in ~/.cache/wine and have been for quite some time, fyi.
I'd also point out that it's useful for systems with multiple users, as then the installers are only downloaded once instead of for each user. Also as Rosanne pointed out, it reduces potential for user error, and potentially allows for a more secure method of getting those addons (e.g., packages could be signed in addition to simply downloading over SSL).
https://bugs.winehq.org/show_bug.cgi?id=39859
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #5 from Vincent Povirk madewokherd@gmail.com --- We could have Wine verify signatures, but instead we rely on a hardcoded hash. I'm not sure https is even used.
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #6 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Vincent Povirk from comment #5)
We could have Wine verify signatures, but instead we rely on a hardcoded hash. I'm not sure https is even used.
Checking a hash is even more secure than relying on signatures, so I do not see any real disadvantage here, no matter if HTTPS is used or not. However, of course its true that issues with the network connection could cause missing gecko/mono, so it might still be useful to provide packages.
I'm not really sure yet whats the best way to do this. It doesn't really belong into the Wine package itself, and we potentially need multiple versions for stable/devel/staging in the same repository. When only the version number is different, older packages might get purged after some time.
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #7 from Austin English austinenglish@gmail.com --- (In reply to Sebastian Lackner from comment #6)
(In reply to Vincent Povirk from comment #5)
We could have Wine verify signatures, but instead we rely on a hardcoded hash. I'm not sure https is even used.
Checking a hash is even more secure than relying on signatures, so I do not see any real disadvantage here, no matter if HTTPS is used or not.
Good point.
I'm not really sure yet whats the best way to do this. It doesn't really belong into the Wine package itself, and we potentially need multiple versions for stable/devel/staging in the same repository. When only the version number is different, older packages might get purged after some time.
Mmm, good point. Perhaps have the gecko/mono package names match the 'branch' name, e.g., wine-gecko-stable, wine-gecko-devel, wine-gecko-staging (not ideal, I realize, but as long as they're in the same repo that may be the best option). wine-gecko-staging may not be needed, at least until y'all start patching gecko in addition to wine ;)
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #8 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Austin English from comment #7)
Mmm, good point. Perhaps have the gecko/mono package names match the 'branch' name, e.g., wine-gecko-stable, wine-gecko-devel, wine-gecko-staging (not ideal, I realize, but as long as they're in the same repo that may be the best option). wine-gecko-staging may not be needed, at least until y'all start patching gecko in addition to wine ;)
Package name could itself contain version, like wine-gecko1.2.3 and then main package could depend/suggest it. They don't change that often to have various flavors of it. Branch name seems a bit too much.
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #9 from Austin English austinenglish@gmail.com --- (In reply to Nikolay Sivov from comment #8)
(In reply to Austin English from comment #7)
Mmm, good point. Perhaps have the gecko/mono package names match the 'branch' name, e.g., wine-gecko-stable, wine-gecko-devel, wine-gecko-staging (not ideal, I realize, but as long as they're in the same repo that may be the best option). wine-gecko-staging may not be needed, at least until y'all start patching gecko in addition to wine ;)
Package name could itself contain version, like wine-gecko1.2.3 and then main package could depend/suggest it. They don't change that often to have various flavors of it. Branch name seems a bit too much.
Sure, that's also an option. The advantage of using branch name is that the dependency can be set once and doesn't have to be updated whenever mono/gecko is updated.
Either way works, it's a minor implementation detail IMO.
https://bugs.winehq.org/show_bug.cgi?id=39859
sworddragon2@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sworddragon2@aol.com
--- Comment #10 from sworddragon2@aol.com --- (In reply to Sebastian Lackner from comment #1)
Is there any benefit compared to using Wines internal downloader?
I wonder why we actually have a downloader for these packages (do we provide the packages the Wine downloader fetches or does it download them from an external source? The startpost sounds like the latter is the case). Distributions like Ubuntu which are creating their own packages should normally provide these additional packages and link them from their Wine package. Users which are downloading/building Wine manually from here can also configure Gecko and Mono manually. If we decide to provide them additionally as packages things are getting even easier.
Are there actually any advantages of providing the downloader? At least it has several disadvantages as a few were already pointed out. Should the downloader eventually get removed once this ticket is fixed?
(In reply to Vincent Povirk from comment #3)
and if you're not paying attention Wine can time out and start the program before the prefix has been fully created.
With an unfinished prefix do you mean that just Gecko and Mono could be missing or that even more things can be missing while the application is already starting? If the latter is the case and it doesn't get fixed with this ticket I think it should get reported with its own ticket if not already done.
https://bugs.winehq.org/show_bug.cgi?id=39859
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shtetldik@gmail.com
--- Comment #11 from Rosanne DiMesio dimesio@earthlink.net --- *** Bug 56315 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #12 from Shmerl shtetldik@gmail.com --- So is there some reason not to package it?
Those who don't want to use the packaged version for whatever reason (i.e. preferring per prefix installation for example) could simply not install the package. But everyone else could benefit from more automation.
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #13 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Shmerl from comment #12)
So is there some reason not to package it?
If you look at the previous discussion, what started as a simple package containing the .msi morphed into issues of naming different versions for each branch, and then including the mono version in the name of each package as well, so they could be installed alongside each other. I agree the latter is a good idea, but on the OBS that would entail creating a new package for each new wine-mono version, as opposed to simply updating the version number of an existing package. In addition, a few years ago wine-mono was changed to offer both shared installs and prefix local installs, adding two more flavors of every type of package.
In addition, much of my original rationale for suggesting this is gone. Downloading became more reliable once the source was moved from Sourceforge to the WineHQ server, and users have become accustomed to not having wine-mono and wine-gecko packages--you are the first person in years to ask for this.
For me it's simply more work than I have time to deal with, with no real need. I've left the bug open in case anyone else wants to take it on.
https://bugs.winehq.org/show_bug.cgi?id=39859
--- Comment #14 from Shmerl shtetldik@gmail.com --- What I think would be useful is simply a package that contains the latest version same way wine itself is packaged. I.e. no need don't overthink it with stuff like "multiple packages installed alongside each other". That can be covered by per prefix installation for those who need it.
I.e. what I mean is simply some wine-mono-devel package for example.
While downloading isn't hard, bloating each prefix with the same thing is still a good thing to avoid, and now I simply copy it manually each time to /opt/wine/mono/..., which can be done by the above package. That was my main point about suggesting to package it.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla