Re: [Mingw-cross-env-list] MXE packages as APT

[Nagaev Boris]

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