Fwd: [Mingw-users] Update for msys-libxml2

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Fwd: [Mingw-users] Update for msys-libxml2

Earnie Boyd
Let's continue this discussion on mingw-dvlpr.

---------- Forwarded message ----------
From: LRN
Date: Mon, Sep 3, 2012 at 12:33 AM
Subject: Re: [Mingw-users] Update for msys-libxml2
To: [hidden email]

Hash: SHA1

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
> http://patchtracker.debian.org/foo/yet_another_patch"
> 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 [1]. 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).

[1] http://lrn.no-ip.info/other/mingw/mingw32/libxml2/2.8.0-2/

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
MinGW-dvlpr mailing list
[hidden email]