make Unladen works in Linux distributions

[Andrea Gasparini]

Hi,
in order to have U-S installable in some distributions and having it to be
FHS copmliant, some things have to be sorted out.

Obviusly I'm assuming that having U-S easily installable will make it far
more tested, and so it'd be a good thing.
In particular, in Debian has been requested an ITP against Unladen-
swallow[1], and I'm trying to get it done.

I have a working but reeeeally unfinished package here[2]. Please do not
use this as a stable package, as it's definitely uncomplete.
Currently it builds in a Ubuntu karmic environment, I'll provide a Debian
based one asap.

In order to progress on this, I've some questions,
a) first of all, a really dumb one: which should be the binary name?
unladen or unladen-swallow? :)

b) Another little thing I'd like to hear from you: should a binary package
ship Q3 version (and Q4 once it'll be out), or it's better using trunk ?
(ATM I'm working on Q3, as it's the current 'released' version)

c) let's come to more serious stuff. The first problem I faced it's the
differences in python .so modules (_ssl, _structs and so on...): of course
python (and a clean unladen as well) search them in /usr/lib/python*/lib-
dynload/, but unladen should not.
A first attempt is set the PYTHONPATH env: of course if works, but using
environment variable is easily breakable, and I'd like to have it works "as
is".
A simple patch I applied simply change Modules/getpath.c and change the
prefix in which unladen search at a first glance for modules.
A better solution would be patching the build system and have it
configurable, as we can send it upstream, I guess... Comments?

d) Last doubt: unladen homepage state that license is "Apache License",
but:
- there's no Apache License file inside sources.
- I've seen no other apache header/boilerplate in any file. (only for
Lib/wsgiref/validate.py, but it's licensed with other licenses as well)
( llvm seems to have his own license, which I'll look at in next days :P )
So, has anyone more clue than me on that argument and can explain to me
which license unladen is distributed with? (maybe I missed something clear,
in this case sorry for bothering :P).

Thanks.
Bye!

[1] http://bugs.debian.org/552135
[2] https://launchpad.net/~gaspa/+archive/ppa/
--
-gaspa-
-----------------------------------------------
-------- https://launchpad.net/~gaspa ---------
----- HomePage: http://gaspa.yattaweb.it ------
-Il lunedi'dell'arrampicatore: www.lunedi.org -

[Collin Winter]

Hey Andrea,

On Fri, Nov 27, 2009 at 6:35 AM, Andrea Gasparini <ga...@yattaweb.it> wrote:
> Hi,
> in order to have U-S installable in some distributions and having it to be
> FHS copmliant, some things have to be sorted out.
>
> Obviusly I'm assuming that having U-S easily installable will make it far
> more tested, and so it'd be a good thing.
> In particular, in Debian has been requested an ITP against Unladen-
> swallow[1], and I'm trying to get it done.
>
> I have a working but reeeeally unfinished package here[2]. Please do not
> use this as a stable package, as it's definitely uncomplete.
> Currently it builds in a Ubuntu karmic environment, I'll provide a Debian
> based one asap.

Thanks for working on this.

> In order to progress on this, I've some questions,
> a) first of all, a really dumb one: which should be the binary name?
> unladen or unladen-swallow? :)

I would prefer "unladen".

> b) Another little thing I'd like to hear from you: should a binary package
> ship Q3 version (and Q4 once it'll be out), or it's better using trunk ?
> (ATM I'm working on Q3, as it's the current 'released' version)

Hmm. I'd say to pull from trunk. There are problems with x86-64
codegen in the Q3 release that have since been fixed.

> c) let's come to more serious stuff. The first problem I faced it's the
> differences in python .so modules (_ssl, _structs and so on...): of course
> python (and a clean unladen as well) search them in /usr/lib/python*/lib-
> dynload/, but unladen should not.
> A first attempt is set the PYTHONPATH env: of course if works, but using
> environment variable is easily breakable, and I'd like to have it works "as
> is".
> A simple patch I applied simply change Modules/getpath.c and change the
> prefix in which unladen search at a first glance for modules.
> A better solution would be patching the build system and have it
> configurable, as we can send it upstream, I guess... Comments?

Thomas, can you comment on this? You have more experience in this area
than I do.

> d) Last doubt: unladen homepage state that license is "Apache License",
> but:
> - there's no Apache License file inside sources.
> - I've seen no other apache header/boilerplate in any file. (only for
> Lib/wsgiref/validate.py, but it's licensed with other licenses as well)
> ( llvm seems to have his own license, which I'll look at in next days :P )
> So, has anyone more clue than me on that argument and can explain to me
> which license unladen is distributed with? (maybe I missed something clear,
> in this case sorry for bothering :P).

It's really under the same license as Python (the PSF license), but
since that wasn't an option on the Google Code form, we were advised
to pick Apache. Unladen Swallow is licensed under the same terms as
Python itself, and we can transfer any necessary rights to the PSF
that we haven't already (though I believe we're square on that).

Thanks,
Collin Winter

[Andrea Gasparini]

In data lunedì 30 novembre 2009 23:15:53, Collin Winter ha scritto:
> Hey Andrea,

Hi Collin,
thanks for your answers,

> > In order to progress on this, I've some questions,
> > a) first of all, a really dumb one: which should be the binary name?
> > unladen or unladen-swallow? :)
>
> I would prefer "unladen".

Me too, so go for unladen. Democracy won. ;)

> > b) Another little thing I'd like to hear from you: should a binary
> > package ship Q3 version (and Q4 once it'll be out), or it's better using
> > trunk ? (ATM I'm working on Q3, as it's the current 'released' version)
>
> Hmm. I'd say to pull from trunk. There are problems with x86-64
> codegen in the Q3 release that have since been fixed.

Fine. Is there a particular revision that you intend to be 'ready' or should I
simply stick with the latest?

> It's really under the same license as Python (the PSF license), but
> since that wasn't an option on the Google Code form, we were advised
> to pick Apache. Unladen Swallow is licensed under the same terms as
> Python itself, and we can transfer any necessary rights to the PSF
> that we haven't already (though I believe we're square on that).

Oh, very nice to hear that.
So, I should "only" find a list of all the copyright holder not in the lists of
upstream python. Is there already one, or should I scan the sources?

Thanks again, bye.
--
-gaspa-
-----------------------------------------------
--------- http://launchpad.net/~gaspa ---------
------ HomePage: iogaspa.altervista.org -------

[Collin Winter]

Hi Andrea,

On Tue, Dec 1, 2009 at 2:42 PM, Andrea Gasparini <ga...@yattaweb.it> wrote:
> In data lunedì 30 novembre 2009 23:15:53, Collin Winter ha scritto:
>> Hmm. I'd say to pull from trunk. There are problems with x86-64
>> codegen in the Q3 release that have since been fixed.
>
> Fine. Is there a particular revision that you intend to be 'ready' or should I
> simply stick with the latest?

I think the latest should be fine.

>> It's really under the same license as Python (the PSF license), but
>> since that wasn't an option on the Google Code form, we were advised
>> to pick Apache. Unladen Swallow is licensed under the same terms as
>> Python itself, and we can transfer any necessary rights to the PSF
>> that we haven't already (though I believe we're square on that).
>
> Oh, very nice to hear that.
> So, I should "only" find a list of all the copyright holder not in the lists of
> upstream python. Is there already one, or should I scan the sources?

See Misc/ACKS for contributors to Unladen Swallow. That file also
includes contributors to Python 2.6.1 (though in a separate section).

Thanks,
Collin Winter

[Thomas Wouters]

It's a tricky proposition. I wouldn't suggest changing just lib-dynload, by any means -- there are differences in .py files as well. The best solution is to use a different prefix, or a different library directory (e.g. /usr/lib/unladen2.6). The latter is not exactly congruent with our assertion that Unladen Swallow is a branch, not a fork, though :-) The least invasive method is to build unladen swallow with a different prefix, then link from /usr/bin/ to there, but I realize that's not exactly FHS-approved.

All things considered, the most appropriate method is to change the library paths, and keep them completely separate from vanilla 2.6 installs.

 

> d) Last doubt: unladen homepage state that license is "Apache License",
> but:
> - there's no Apache License file inside sources.
> - I've seen no other apache header/boilerplate in any file. (only for
> Lib/wsgiref/validate.py, but it's licensed with other licenses as well)
> ( llvm seems to have his own license, which I'll look at in next days :P )
> So, has anyone more clue than me on that argument and can explain to me
> which license unladen is distributed with? (maybe I missed something clear,
> in this case sorry for bothering :P).

It's really under the same license as Python (the PSF license), but
since that wasn't an option on the Google Code form, we were advised
to pick Apache. Unladen Swallow is licensed under the same terms as
Python itself, and we can transfer any necessary rights to the PSF
that we haven't already (though I believe we're square on that).

Thanks,
Collin Winter

> [1] http://bugs.debian.org/552135
> [2] https://launchpad.net/~gaspa/+archive/ppa/
> --
> -gaspa-
> -----------------------------------------------
> -------- https://launchpad.net/~gaspa ---------
> ----- HomePage: http://gaspa.yattaweb.it ------
> -Il lunedi'dell'arrampicatore: www.lunedi.org -
>

--
Thomas Wouters <twou...@google.com>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

[Andrea Gasparini]

Hi Thomas,

> It's a tricky proposition. I wouldn't suggest changing just lib-dynload,
> by any means -- there are differences in .py files as well.

Yes, that's right for .pyc too, python2.6 can't work with unladen's pyc,
and viceversa.
Anyway patching getpath.c as I currently do will change this behavior as

well.

> The best
> solution is to use a different prefix, or a different library directory
> (e.g. /usr/lib/unladen2.6). The latter is not exactly congruent with
> our assertion that Unladen Swallow is a branch, not a fork, though :-)

I understand your thought, but having it FHS compliant is exactly what I'm
working for (otherwise it can't simply reach official repositories), so
it's almost essential from my point of view.

Anyway, having a patch that makes the "python2.6" part of the path
configurable with some configure option would be in my mind the best
solution, as we can also send it to upstream python.

Moving on, is what you said that we should use a prefix (let's say for
example: /usr/lib/unladen/) and have all installed there? ( i.e:
/usr/lib/unladen/lib/python2.6 /usr/lib/unladen/lib/python2.6/lib-dynload
/usr/lib/unladen/bin/ etc... )
Ok, if I'll be able to move everything that's not "library" out of there
without breaking unladen and FHS compliancy, this can be a (tricky)
solution.

The remaining possible solution is have a patch distributed with the
packaging stuff. Although is what I currently ship in my package, I
seriously dislike this, so I'll go with this only if we can't find a common
solution.

Thanks for your support, see you! :)