[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-cross-env-list] MXE packages as APT
From: |
Nagaev Boris |
Subject: |
Re: [Mingw-cross-env-list] MXE packages as APT |
Date: |
Sun, 28 Jun 2015 11:07:37 +0000 |
Hi Volker,
On Sun, Jun 28, 2015 at 10:24 AM, Volker Grabsch <address@hidden> wrote:
> Dear Boris,
>
> This is really great work!
>
> Regarding your last question, it would be interesting to hear more
> opinions from others on that.
>
>
> Nagaev Boris schrieb:
>> 3. The tool was renamed to build-pkg.lua and is ready to be merged into MXE
>> [2].
>
> Pull request merged.
>
> However, I noticed the following strange comment at the beginning
> of tools/build-pkg.lua:
>
> -- mxedeb, Build DEB packages from MXE packages
> -- Instructions: http://mxe.redjohn.tk
>
> This seems to refer to the old package name. (Since this is just a
> comment, I merged the pull request nevertheless.)
Fixed in https://github.com/mxe/mxe/pull/742
>> 5. While running the tool, location of MXE directory MUST be
>> /usr/lib/mxe (same as the directory where it is installed to).
>> Otherwise paths in many files are broken (e.g., in mxe-conf.cmake).
>
> It seems that this is neither documented nor checked anywhere.
>
> Is it possible to perform a very simple check at the beginning
> of the script?
>
> For example, just complain if /usr/lib/mxe doesn't seem to be
> an MXE directory. (Or, maybe you find some better criterion.)
It is checked:
assert(trim(shell('pwd')) == MXE_DIR,
"Clone MXE to " .. MXE_DIR)
>> 7. Size of packages is rather big. Installing Qt and Boost requires
>> downloading 600 Mb. Shall we strip binary files? Packages' sizes would
>> decrease by times.
>
> I agree with the sentiment to keep package sizes small. We already
> try to reduce sizes by not building (and installing) documentation.
>
> However, this is always a secondary goal, while the primary goal is
> "feature completeness" in the sense that when trouble starts, all you
> need is there. This is especially important for Debian packages.
>
> That's why I don't think we should strip library files such as .a or
> .dll files. So our MXE packages are more like the lib-*-dev Debian
> packages and no so much like the simple lib-* packages.
>
> On the other hand, I believe that stripping additional stuff such as
> .exe files should be fine. These are meant to be copied to the target
> system anyway (or to be run via Wine). In other words, these things
> aren't part of the compiling/debugging efforts.
>
> Any other opinions?
>
> What should we strip? How far should we go to keep package sizes small?
>
>
I have discovered a new problem. Installing same packages for multiple
targets results in dpkg errors.
# apt-get install mxe-x86-64-w64-mingw32.static-gcc-mpfr
mxe-i686-w64-mingw32.static-gcc-mpfr
Selecting previously unselected package mxe-x86-64-w64-mingw32.static-gcc-mpfr.
Unpacking mxe-x86-64-w64-mingw32.static-gcc-mpfr (from
.../mxe-x86-64-w64-mingw32.static-gcc-mpfr_3.1.3_all.deb) ...
dpkg: error processing
/var/cache/apt/archives/mxe-x86-64-w64-mingw32.static-gcc-mpfr_3.1.3_all.deb
(--unpack):
trying to overwrite '/usr/lib/mxe/usr/share/info/mpfr.info', which is
also in package mxe-i686-w64-mingw32.static-gcc-mpfr 3.1.3
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Possible workaround: add the following arguments to apt-get command:
-o Dpkg::Options::="--force-overwrite"
--
Best regards,
Boris Nagaev