Mono vs. Gecko packaging discrepancies
I noticed a number of discrepencies in the way the Gecko and Mono addons are packaged: * One uses ...<arch>-<version>... the other ...<version>-<arch>... * One uses .bz2 files, the other .gz. * For one the tar file must be extracted to "../<addon>", for the other just "../". * One stores the source in ...<addon>-<version>.tar*, the other in ...<addon>-<version>-src.tar*. None of this is major but it just makes writing scripts that deal with addons a pain for seemingly no good reason. Could we standardize? After reviewing the differences I think I prefer the way Gecko does things: * bzip2 is pretty widely adopted and compresses better so I'd standardize on that. I'd be game for xz or even zstd too (xz is one of the formats used for the Linux kernel tarballs so maybe it's mainstream enough). * Putting the 'architecture' last makes it easier to build the tar filename from the directory name. So I would standardize on wine-<addon>-<version><arch>.tar.bz2. And I'd treat the source as yet another architecture. That would give: wine-mono-4.9.4-src.tar.bz2 wine-mono-4.9.4-bin.tar.bz2 or wine-mono-4.9.4.tar.bz2 like the msi file or wine-mono-4.9.4-all.tar.bz2 in Debian fashion wine-gecko-2.47.1-src.tar.bz2 wine-gecko-2.47.1-x86.tar.bz2 wine-gecko-2.47.1-x86_64.tar.bz2 * For the directory where to extract the file I prefer '../<addon>/' because that matches the directory for msi files. Also it makes it easier to create a symlink to that directory and not have to update it when a new version is released (my Wine build directories are not all in the same location). -- Francois Gouget <fgouget(a)codeweavers.com>
On 24.01.2020 17:00, Francois Gouget wrote:
I noticed a number of discrepencies in the way the Gecko and Mono addons are packaged:
* One uses ...<arch>-<version>... the other ...<version>-<arch>... * One uses .bz2 files, the other .gz. * For one the tar file must be extracted to "../<addon>", for the other just "../". * One stores the source in ...<addon>-<version>.tar*, the other in ...<addon>-<version>-src.tar*.
None of this is major but it just makes writing scripts that deal with addons a pain for seemingly no good reason. Could we standardize?
After reviewing the differences I think I prefer the way Gecko does things:
* bzip2 is pretty widely adopted and compresses better so I'd standardize on that. I'd be game for xz or even zstd too (xz is one of the formats used for the Linux kernel tarballs so maybe it's mainstream enough).
It looks like the main Wine package uses xz and I'm with switching to that.
* Putting the 'architecture' last makes it easier to build the tar filename from the directory name. So I would standardize on wine-<addon>-<version><arch>.tar.bz2. And I'd treat the source as yet another architecture. That would give: wine-mono-4.9.4-src.tar.bz2 wine-mono-4.9.4-bin.tar.bz2 or wine-mono-4.9.4.tar.bz2 like the msi file or wine-mono-4.9.4-all.tar.bz2 in Debian fashion wine-gecko-2.47.1-src.tar.bz2 wine-gecko-2.47.1-x86.tar.bz2 wine-gecko-2.47.1-x86_64.tar.bz2
* For the directory where to extract the file I prefer '../<addon>/' because that matches the directory for msi files.Also it makes it easier to create a symlink to that directory and not have to update it when a new version is released (my Wine build directories are not all in the same location).
Yes, I agree that subdir is nicer. Note that you may also just use /opt/wine/ instead of symlinks. Thanks, Jacek
On Fri, 24 Jan 2020, Jacek Caban wrote: [...]
It looks like the main Wine package uses xz and I'm with switching to that.
Works for me. [...]
* For the directory where to extract the file I prefer '../<addon>/' because that matches the directory for msi files.Also it makes it easier to create a symlink to that directory and not have to update it when a new version is released (my Wine build directories are not all in the same location).
Yes, I agree that subdir is nicer. Note that you may also just use /opt/wine/ instead of symlinks.
The Gecko and Mono directories are being updated by a script that runs in a non-root account. I guess I could make parts of /opt/wine owned by the account this script runs under for my machines but I'm not very fond of that. It would also mean that wt-bot [1] requires one to set up /opt/wine is this special way. [1] https://github.com/fgouget/wt-daily/blob/master/wt-bot#L631 -- Francois Gouget <fgouget(a)codeweavers.com>
* One uses ...<arch>-<version>... the other ...<version>-<arch>...
None of Wine Mono's build artifacts include an architecture in the filename. Bin is not an architecture. Technically, the msi is x86. If/when we have arm support, we'll need a separate msi, and we may want a separate tarball as well. Would it be too confusing to list x86 as an architecture when it includes x86_64 files too?
On Mon, 3 Feb 2020, Vincent Povirk (they/them) wrote:
* One uses ...<arch>-<version>... the other ...<version>-<arch>... [...] * Putting the 'architecture' last makes it easier to build the tar
None of Wine Mono's build artifacts include an architecture in the filename. Bin is not an architecture.
I know. That's why I put architecture in quotes in the second sentence above. I'm looking at this entirely from the filename structure point of view and how hard it is to build the URL of what I need to download.
Technically, the msi is x86. If/when we have arm support, we'll need a separate msi, and we may want a separate tarball as well.
Would it be too confusing to list x86 as an architecture when it includes x86_64 files too?
I would consider it acceptable in that if we have one file with 'arm' (or some equivalent) somewhere in it, then it makes sense to label the other with something indicating it's for the 8086 descendants. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
I've pushed some changes to the master branch. The build artifacts for Wine Mono 5.0, when it's ready, will be as follows: wine-mono-5.0.0-src.tar.xz wine-mono-5.0.0-x86.tar.xz wine-mono-5.0.0-x86.msi If and when there is an arm version, it will have "arm" in the filename instead of x86. There will be no x86_64 or aarch64 downloads because both 32-bit and 64-bit files will be included in a single download. That's going to mean updating addons.c and winemono.php on the website.
On Wed, 5 Feb 2020, Vincent Povirk (they/them) wrote:
I've pushed some changes to the master branch. The build artifacts for Wine Mono 5.0, when it's ready, will be as follows:
wine-mono-5.0.0-src.tar.xz wine-mono-5.0.0-x86.tar.xz wine-mono-5.0.0-x86.msi
If and when there is an arm version, it will have "arm" in the filename instead of x86. There will be no x86_64 or aarch64 downloads because both 32-bit and 64-bit files will be included in a single download.
Sounds good to me. -- Francois Gouget <fgouget(a)codeweavers.com>
participants (4)
-
Francois Gouget -
Francois Gouget -
Jacek Caban -
Vincent Povirk (they/them)