Message-ID: <4546D720.9030802@cwilson.fastmail.fm>
Date: Mon, 30 Oct 2006 23:54:56 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [patch] cygport
References: <453C180C DOT 4060206 AT cwilson DOT fastmail DOT fm> <4546B1FA DOT 4070309 AT users DOT sourceforge DOT net>
In-Reply-To: <4546B1FA.4070309@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Yaakov S (Cygwin Ports) wrote:
> Charles Wilson wrote:
> | The attached patch (+ two new files) enables cygport to build
> | "relocatable" packages using the framework devised by Bruno Haible -- if
> | the upstream source supports it.  Currently, only libiconv and gettext
> | support this feature (coincidentally, the upstream maintainer of both
> | packages is...Bruno Haible).
> 
> Forgive me for my ignorance on the topic, but what is gained through
> enabling relocatibility?  FWIW, I don't see Gentoo[1][2] using it, for
> example.  Do other distros use it?

Many times packages are compiled with hard-coded paths to resources. 
E.g. if you compile foo with --prefix=/my/local/area, it's likely that 
data will be installed into /my/local/area/share/foo/*, and that the 
path "/my/local/area/share/foo" will be hard-coded into libfoo.so and/or 
foo.exe. (also, -rpath on ELF systems, etc)

But what if you want to make a binary release that can be installed by 
some user into ~/.local-packages/?  (or /mnt/usb-stick/?)  What if you 
*don't know* where the end-user will install the binary package?  (Try 
http://portableapps.com/ for a real-life example, or Movable Python 
http://www.voidspace.org.uk/python/movpy/)

Certainly, gentoo has no use for this; they expect everyone to recompile 
everything everytime.  Since GentooUserBob will compile the package 
specifying his desired installation prefix, he doesn't care about 
relocation after the build is complete.


Now, the Bruno said (way back when he first introduced this feature)

"I hope that people will learn when to use --enable-relocatable by
themselves. For example, I don't think a Linux distributor should use
--enable-relocatable for anything installed in /usr - it would only
be bloat that makes the system slower."
http://mail.gnu.org/archive/html/bug-gnulib/2003-04/msg00014.html

And that's true for the official cygwin dist of gettext and libiconv, 
too -- the official cygwin gettext and libiconv packages are not built 
with relocation support.  However, I always do a test build WITH 
relocation, to make sure nothing has broken. [*]

Often, something /has/ broken, and this little exercise exposes it -- 
and sometimes the problem thus exposed also affects the non-relocatable 
build, but wasn't exposed in the "regular" build.  So adding the ability 
to automate relocatable builds within the cygport framework would 
certainly help ME quite a bit (and not just on gettext/libiconv.  I'm 
working on adding relocation support to two other packages, also -- not 
that the official cygwin distributed versions would actually use that 
support, either).


The original relocation proposal gives a much better justification for 
relocation in general than I do:
http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html

--
Chuck

[*] actually, I do a whole sequence of test builds (thanks to the fact 
that libiconv and gettext are interdependent):

WITH RELOCATION
   1. libiconv --disable-nls
   2. gettext (link against #1, NOT installed libiconv)
   3. libiconv --enable-nls (link against #2)
        run test suite
   4. gettext (link against #3)
        run test suite

then, WITHOUT RELOCATION
   5. libiconv --disable-nls
   6. gettext (link against #5, NOT installed libiconv)
   7. libiconv --enable-nls (link against #6)
        run test suite
   8. gettext (link against #7)
        run test suite

The packages generated in #7 and #8 are the ones that get uploaded for 
cygwin.  And you wonder why I don't update libiconv/gettext very often...

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/