---------- Forwarded message ----------
Date: Mon, Sep 3, 2012 at 12:33 AM
Subject: Re: [Mingw-users] Update for msys-libxml2
To: [hidden email]
-----BEGIN PGP SIGNED MESSAGE-----
On 03.09.2012 7:33, Charles Wilson wrote:
> On 9/2/2012 5:05 PM, LRN wrote:
>> As a sort of experiment, i've tried to make a msys-libxml2
>> package with mgwport. Results are attached.
>> So far my impressions of mgwport are these: 1) All patches are
>> squished into one file. Bad.
> This is not necessarily the case. If you list the individual
> patches in your .mgwport file separately:
> PATCH_URI="http://some.web.addr/git/tree/whatever.patch > some_local_patch_file1 some_other_patch_file2
> then they will stay "separate". It's only the "unidentified"
> changes between your orig_src and src dirs that get "squished".
I've used mingw32-binutils and msys-dos2unix packages as examples.
They don't do this sort of thing. I'll keep that feature in mind.
>> 4) Impossible to hook to the packaging process (no src_package or
>> such). This is not a problem for msys-libxml2, but will pose
>> some difficulties for other packages i might create, because they
>> have multiple prefixes. make_etc_defaults might help, but i'm not
>> sure how make_etc_defaults will work when a mingw32 package needs
>> to place some files in /usr/etc.
> Frankly, as per policy mingw32 packages should NEVER place
> anything outside of /mingw (and mingw "etc" stuff should be in
> /mingw/etc, not /usr/etc). "Multiple prefixes" is a really bad
> idea, since such packages would not satisfy the mingw.org packaging
> guidelines, and would likely confuse mingw-get.
> If you can split such offerings into *separate* packages (e.g. on
> cygwin gcc-tools-automake (1.10) goes into /opt/gcc-tools, and is
> separate and distinct from automake1.10 which goes into /usr as
> per normal -- even tho both are just "automake-1.10" compiled with
> a different prefix) -- then that could probably work. Neither
> cygport nor mgwport/msysport like it very much tho.
Actually, my intention IS to make different "binary" packages from a
single source package.
To see what i mean, look at mingw32-libxml2-2.8.0-2 . While being
mostly mingw32, it also provides a single msys-1.0.17 package, which
contains an /etc/profile.d/xml_catalog.sh file, which goes into
/usr/etc/... on installation (the file itself is subsystem-agnostic,
and will DTRT for both MinGW and MSYS modes).
pkgbuild.sh generates it by manually placing this file into
$instdir/etc, cd'ing into $instdir (instead if normal $instdir$prefix
used for other packages) and packing it from there.
Then, there's also the libxml2-2.8.0-2-mingw32-python-2.7.tar.lzma
package, that is marked as mingw32 (should it be?), but is installed
into Python lib subdirectory. Again, it's packed from
$instdir$prefix/lib/python* instead of $instdir$prefix, with proper
version added to the package name.
Installation is handled by my custom Python script (my packages have
no mingw-get xml metadata, so i have to use other tools), which,
obviously, knows where its Python lib directory is.
I'm not sure how to even attempt to do that with mgwport.
> The whole point of the *port project(s) is to standardize such
> things like installation prefixes and options.
Standardization is a double-edge sword. It means that mgwport evolves
slowly, as all changes must be backward-compatible with all packages
ever released, and that all new features must first be integrated into
mgwport, before a package can use them.
The downside of my appropach is that when a new buildscript change
happens, i have to update all of the affected packages (which is why
i'm experimenting with mgwport at the moment - debug info generation
affects _all_ of the 126 packages that i've made so far).
So far i haven't seen a good compromise (other than just providing
package tools as a set of discrete feature-tools, letting package
maintainer decide which tools to use, and how, and then just having
lots of package maintainers updating packages as needed - this is,
basically, what Debian does).