FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-17-2009, 01:44 PM
Josselin Mouette
 
Default Python related changes for unstable/squeeze

Le mardi 17 février 2009 * 15:03 +0100, Bernd Zeimetz a écrit :
> > - Can you guys please finally sit down and agree on one solution for
> > handling python modules? I still think that having two (slightly
> > different) ways of doing this task is not the way to go. I really do
> > not see technical reason for this situation. I have no preference at
> > all and I'm actually using both things in my packages, but I really
> > do not think it is way to go. And it would be great if we can have
> > single tool, which gets more testing and will have less bugs than
> > current concurrent solutions.
>
> Ack. Please guys, get together, discuss it in a *sane* way (why do I fear that's
> not possible...) and merge both tools or drop both of them and do something else
> useful - together.

You really can’t say I’m not trying to discuss. But it takes at least
two persons to discuss, and Matthias has been ignoring all technical
discussions about Python packaging for years.

This is not a technical problem. The technical divergences can be solved
if consensus is reached about them or if a decision body (TC or GR)
forces them. This is purely a person problem: Matthias is clearly not
willing to maintain python-central correctly nor to make it evolve
according to the needs of developers. These are two very good reasons to
keep maintaining an alternative.

--
.'`. Debian 5.0 "Lenny" has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and
`- told that if you don't install Lenny, he'd melt your brain.
 
Old 02-17-2009, 03:02 PM
Russ Allbery
 
Default Python related changes for unstable/squeeze

Felipe Sateler <fsateler@gmail.com> writes:
> Josselin Mouette wrote:

>> "XS-Python-Version: current" means the following: even if several
>> Python versions are available, the module will only be built for the
>> default version. *This declaration has nothing to do with the supported
>> Python versions.* If we really needed it, it should go in another
>> field.
>
> I'm not sure what you mean. If a module is only built for one version,
> then the other versions are not supported.

However, the correct way to represent this is with:

XS-Python-Version: 2.5

(for example). Since the meaning of "current" changes, you shouldn't use
it for this purpose.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-17-2009, 03:09 PM
Holger Levsen
 
Default Python related changes for unstable/squeeze

Hi Joss,

On Dienstag, 17. Februar 2009, Josselin Mouette wrote:
> You really can’t say I’m not trying to discuss.

I'm not sure if one cannot say this, as you "nicely" show in the following
words that you definitly totally fail to discuss

> But it takes at least
> two persons to discuss, and Matthias has been ignoring all technical
> discussions about Python packaging for years.
>
> This is not a technical problem. The technical divergences can be solved
> if consensus is reached about them or if a decision body (TC or GR)
> forces them. This is purely a person problem: Matthias is clearly not
> willing to maintain python-central correctly nor to make it evolve
> according to the needs of developers. These are two very good reasons to
> keep maintaining an alternative.

Hint: it takes two to discuss. If I were Matthias and would read those
statements, I probably wouldnt see added value in talking to you neither.


regards,
Holger
 
Old 02-17-2009, 03:18 PM
Guy Hulbert
 
Default Python related changes for unstable/squeeze

On Tue, 2009-17-02 at 17:09 +0100, Holger Levsen wrote:
> Hi Joss,
>
> On Dienstag, 17. Februar 2009, Josselin Mouette wrote:
> > You really can’t say I’m not trying to discuss.
>
> I'm not sure if one cannot say this, as you "nicely" show in the following
> words that you definitly totally fail to discuss

I disagree. Joss is posting to the list.

>
> > But it takes at least
> > two persons to discuss, and Matthias has been ignoring all technical
> > discussions about Python packaging for years.
> >
> > This is not a technical problem. The technical divergences can be solved
> > if consensus is reached about them or if a decision body (TC or GR)
> > forces them. This is purely a person problem: Matthias is clearly not
> > willing to maintain python-central correctly nor to make it evolve
> > according to the needs of developers. These are two very good reasons to
> > keep maintaining an alternative.
>
> Hint: it takes two to discuss. If I were Matthias and would read those
> statements, I probably wouldnt see added value in talking to you neither.

Joss says that Matthias has been unresponsive "for years". That could
be a factual statement ... I think you might give Matthias some time to
respond himself before jumping in.

>
>
> regards,
> Holger

--
--gh



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-17-2009, 04:16 PM
Gustavo Noronha
 
Default Python related changes for unstable/squeeze

Hey,

On Tue, 2009-02-17 at 17:09 +0100, Holger Levsen wrote:
> > But it takes at least
> > two persons to discuss, and Matthias has been ignoring all technical
> > discussions about Python packaging for years.
> >
> > This is not a technical problem. The technical divergences can be solved
> > if consensus is reached about them or if a decision body (TC or GR)
> > forces them. This is purely a person problem: Matthias is clearly not
> > willing to maintain python-central correctly nor to make it evolve
> > according to the needs of developers. These are two very good reasons to
> > keep maintaining an alternative.
>
> Hint: it takes two to discuss. If I were Matthias and would read those
> statements, I probably wouldnt see added value in talking to you neither.

As someone who has been following this discussion from the beginning, I
have to disagree with you. Josselin has been actively pointing
technical, practical reasons to implement the solution in a way which is
different to that Matthias chooses to implement.

>From my perspective Matthias failed to respond to that criticism, and
ignored the possibility of consensus building taking advantage of the
fact that he maintains the Python interpreter packages (and the fact
that he is able to push things 100% his way into Ubuntu).

See you,

--
Gustavo Noronha <kov@debian.org>
Debian Project


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-17-2009, 05:09 PM
Ondrej Certik
 
Default Python related changes for unstable/squeeze

On Tue, Feb 17, 2009 at 6:44 AM, Josselin Mouette <joss@debian.org> wrote:
> Le mardi 17 fvrier 2009 15:03 +0100, Bernd Zeimetz a crit :
>> > - Can you guys please finally sit down and agree on one solution for
>> > handling python modules? I still think that having two (slightly
>> > different) ways of doing this task is not the way to go. I really do
>> > not see technical reason for this situation. I have no preference at
>> > all and I'm actually using both things in my packages, but I really
>> > do not think it is way to go. And it would be great if we can have
>> > single tool, which gets more testing and will have less bugs than
>> > current concurrent solutions.
>>
>> Ack. Please guys, get together, discuss it in a *sane* way (why do I fear that's
>> not possible...) and merge both tools or drop both of them and do something else
>> useful - together.
>
> You really can't say I'm not trying to discuss. But it takes at least
> two persons to discuss, and Matthias has been ignoring all technical
> discussions about Python packaging for years.
>
> This is not a technical problem. The technical divergences can be solved
> if consensus is reached about them or if a decision body (TC or GR)
> forces them. This is purely a person problem: Matthias is clearly not
> willing to maintain python-central correctly nor to make it evolve
> according to the needs of developers. These are two very good reasons to
> keep maintaining an alternative.

Unfortunately from both of you I only met Matthias in person (in
Prague at the Ubuntu Developer Summit), but what I understood is that
there are some technical reasons why python-central is better. But
those should be resolved by discussing it on the list, coming to a
consensus and then fixing it by merging the packages or starting from
scratch.

Josselin, it's true that if you were discussing with me in the same
tone as you are with Matthias, it will not make me very happy (as many
people have pointed out), but I appreciate that you discuss and reply
to criticisms and that's the most important.

So Matthias, please, try to come to this list and get this resolved
once and for all. Failing to discuss and pushing things your way is
bad.

Ondrej


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-17-2009, 05:34 PM
Josselin Mouette
 
Default Python related changes for unstable/squeeze

Le mardi 17 février 2009 * 10:09 -0800, Ondrej Certik a écrit :
> Unfortunately from both of you I only met Matthias in person (in
> Prague at the Ubuntu Developer Summit), but what I understood is that
> there are some technical reasons why python-central is better.

I’d be happy to hear these reasons; I’m always eager to improve
python-support when there is room to.

Currently I know one reason why you could consider python-central
better: this is because it installs files at the same place the upstream
packages do. This avoids breaking some (bad) packages’ expectations. I
have two remarks about this:
* The python-support README has documented for long how to work
around this problem if you encounter it (remember it concerns a
handful of packages).
* If python-support was the only tool to write files
to /usr/lib/pythonX.Y/site-packages, there would be no problem
with using this directory. However there are packages using
python-central and packages shipping files directly there, so it
is simply not possible without losing the advantages of
python-support (like, not introducing 50 RC bugs every time
something is changed).

Besides, I could show you several reasons why python-support is
superior, and at least one why python-central is broken.

> Josselin, it's true that if you were discussing with me in the same
> tone as you are with Matthias, it will not make me very happy

But I am not using this tone with you, and the reason is that you are
behaving correctly.

Cheers,
--
.'`. Debian 5.0 "Lenny" has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and
`- told that if you don't install Lenny, he'd melt your brain.
 
Old 02-17-2009, 06:09 PM
Vincent Bernat
 
Default Python related changes for unstable/squeeze

OoO Lors de la soire naissante du mardi 17 fvrier 2009, vers 17:09,
Holger Levsen <holger@layer-acht.org> disait*:

>> This is not a technical problem. The technical divergences can be solved
>> if consensus is reached about them or if a decision body (TC or GR)
>> forces them. This is purely a person problem: Matthias is clearly not
>> willing to maintain python-central correctly nor to make it evolve
>> according to the needs of developers. These are two very good reasons to
>> keep maintaining an alternative.

> Hint: it takes two to discuss. If I were Matthias and would read those
> statements, I probably wouldnt see added value in talking to you
> neither.

IMO, this is unfortunate but it is really difficult to discuss with
Matthias. Most comments are just ignored.

For example:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474630
Matthias made a short statement about the problem and ignored the rest
of the discussion. I had to switch to python-central to solve this
bug. Josselin added a functionality to python-support to circumvent this
limitation.

Here is another example:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475440
Some fixes were proposed to circumvent this problem but bug was just
marked as "won't fix". This hits all users using easy_install (which is
fairly popular among Python developers). And this bug is in Lenny.
--
A TRAINED APE COULD NOT TEACH GYM
A TRAINED APE COULD NOT TEACH GYM
A TRAINED APE COULD NOT TEACH GYM
-+- Bart Simpson on chalkboard in episode AABF15
 
Old 02-17-2009, 11:20 PM
Piotr Ożarowski
 
Default Python related changes for unstable/squeeze

[Matthias Klose, 2009-02-16]
> Piotr Ożarowski schrieb:
> >> - 2.5 is superseded by 2.6; currently there doesn't seem to be
> >> a reason to ship 2.5 and modules for 2.5 with the next stable
> >> release. The upstream 2.5 maintainance branch doesn't see bug
> >> fixes anymore, only security releases will be made from this
> >> branch.
> >
> > What about a smooth upgrade path for those who use Python2.5 for their (3rd
> > party) applications? I think Python 2.6 should be default in Squeeze and Python
> > 2.4&2.5 in supported.

FTR: I meant "2.5" in supported and "2.4" in "semi-supported" (as in only
Zope related modules should be supported for this version)

> always having the default version of the stable release included in the next
> release would mean that Debian releases keep up with Python release, or we would
> end up shipping more than two 2.x versions. Same if 2.7 gets released in time.

what if administrators will install some local applications that will
have python2.5 hardcoded in shebang? Do you want to provide
python2.5->python2.6 symlink? I'm not sure it's a good idea. Are you
sure Python 2.6 (and all modules/extensions) are 2.5-compatible? Or do
you simply want to add an instruction in release notes what to do in
such situation (but then again: are you sure 2.6 and 2.5 are compatible?)

> /usr/local/lib/pythonX.Y/site-packages will only be used if you install your
> own python, and use this interpreter to call setup.py install. When using the
> python (>= 2.6) provided by Debian without to call setup.oy install
> --install-layout=deb, the installation will go to
> /usr/local/lib/pythonX.Y/dist-packages, without --install-layout it will go to
> /usr/lib/pythonX.Y/dist-packages.

/usr/local/lib/pythonX.Y/site-packages should definitely *not* be
symlinked to /usr/local/lib/pythonX.Y/dist-packages then (and vice versa)

> > I really like the idea of using the same location for both tools, please note
> > that you'll have to change pycentral to use something like /usr/lib/pyshared
> > (for Python extensions)
>
> where is the advantage of having a /usr/lib/pyshared?

it's one of the "sacrifices" you'll have to make if you want
/usr/share/py{,3}shared to be used by other tool(s). I see no way to use
Python's official path in pysupport in its current design.

Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff is
probably the worst of it's bugs, but maintainer is aware of this and
will most probably fix it during the move to
/usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
convince him, leave it to me

Once we'll agree on the paths, I will rise another problem I want to
discuss before we'll start converting packages but lets leave it for
later (note that I don't want to merge both tools, it's not possible, I
want a situation where one helper can Conflict&Provide the other one -
yeah, you'll say "it's not possible! You're crazy!" - we'll see about
that :-)

Oh, one more thing: for now, I'm using both helper tools (to be aware of
their advantages/disadvantages and to be able to help my sponsorees -
please note that I never forced my sponsoree to use one of the helpers -
see FAQ#2 [1]), it's time however to decide which one will be my
winner - I'll decide that in next weeks (maybe months, but it
will happen sooner than later - my packages in Squeeze will use one
helper only!) and once I decide that, I will force all my sponsorees to
choose the same one (by refusing to upload package that uses the other
one)

IMNSHO

[placeholder for all those who want to make jokes about what I wrote in
next few lines - feel free to also make fun of me on #debian-python - at
least I will feel a little bit better after writing so many immodest
stuff ;]

If you care how many packages are using your tool, my preference should
matter to you as I'm the one who sponsored more Python related Debian
packages than anyone else in Debian - right now no one else has more
sponsored packages on QA page than I do (Anibal listed first on this[2]
page has less sponsored packages) and besides Sandro and Bernd, I'm the
only one who does regular sponsoring in PAPT and DPMT (which are
becoming more popular every day, there are rumors about magic way to get
a Python related package very well reviewed and really fast sponsored in
Debian even on #ubuntu-motu and people are prefering to do this via
Debian, really!) - I will also try to convince Bernd, Sandro and few
other DDs (Ana: that includes you! to use the same helper.

anyway, my army[3] and I can make a difference when it comes about
popconf stats. ;-P

[1] http://people.debian.org/~piotr/sponsor
[2] http://merkel.debian.org/~myon/sponsorstats/
[3] http://people.debian.org/~piotr/sponsorees.png

> > I don't like python (<< X.Y) dependencies, it's so... old-policy like.
> > Not a good idea, IMHO
>
> well, just "not liking" is a weak argument.

that's OLD-POLICY-LIKE, that should be enough argument, IMO ;-P

Providing such ugly dependencies and requiring to (N)MU (there are no
binNMUs for arch:all packages) once we'll introduce new Python version
is just bad (still "IMHO")

Please also note that pysupport has a nice feature (that IMO should be
disabled by default, though (I'll file a bug soon), of byte compiling
modules for officially not supported Python versions (if installed *and*
maintainer claims it's compatible with that version) - this helps f.e.
if one installed python2.6 right now (or python2.5 in Etch)

> >> - The removal of a python version will cause the need for massive
> >> rebuilds. because many python extensions currently have
> >> dependencies of the form pythonX.Y-foo. There is nothing what
> >> can be done now for the upcoming removal, but those dependencies
> >> should not be there by default. This is 2.4 of the python policy,
> >> but many packages tend to ignore that.
> >
> > python-support supports namespace packages and it does it good. I didn't want
> > it to be enabled by default but since Joss provided a way to disable it (see
> > #459468) I think it's OK.
> >
> > python-central should implement the same behaviour, IMHO
>
> As I did write above, the support for namespace packages should be implemented
> using diversions. It's ok to generate these by a packaging helper.

I really think there's nothing wrong with pysupport's implementation of
namespace packages now; using diversions (we're talking about dpkg
diversions, right?) doesn't seem to be a good use of this dpkg feature -
it's not meant to be used for such purpose (I might be wrong, I'm no
dpkg expert)

> > Just one more issue: what about "current" issue? Although I protested when
> > others wanted to remove it, now I agree it's useless. All packages that depend
> > on it (Python applications mostly) should use private directories and thus not
> > pollute the global namespace (we should add this to the Python policy, IMO)
>
> "current" is also useful to only provide a public module for just the default
> version. I'm unsure what you mean with when talking about the above mentioned
> "issue"

and what's wrong in providing this module for other Python versions?

"issue" as it's not really needed and is one of the reasons our Python
Policy is in a state that no one really knows what is still valid and what
is not.

--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
 
Old 02-18-2009, 12:06 AM
Josselin Mouette
 
Default Python related changes for unstable/squeeze

Le mercredi 18 février 2009 * 01:20 +0100, Piotr Ożarowski a écrit :
> > where is the advantage of having a /usr/lib/pyshared?
>
> it's one of the "sacrifices" you'll have to make if you want
> /usr/share/py{,3}shared to be used by other tool(s). I see no way to use
> Python's official path in pysupport in its current design.
> Sure, pysupport is not perfect. Using /var/ for bytecompiled stuff is
> probably the worst of it's bugs, but maintainer is aware of this and
> will most probably fix it during the move to
> /usr/{share,lib}/py{,3}shared - and I have a reasons to believe that
> he'll use this path if you decide to use /usr/lib/py{3,}shared (I'll
> convince him, leave it to me

It seems that there is one thing you got wrong here. /usr/lib/pyshared
will be for C extensions and data that varies from a Python version to
another (like /usr/lib/python-support/$package currently). It is not the
place where the symlinks and byte-compiled files will land after running
the script.

For this last thing, I initially thought of
using /usr/lib/pythonX.Y/python-support, but I guess the rtinstall
script of python-central will mess with that directory, so in the end
I’d prefer to find something else. Maybe /usr/lib/pymodules/pythonX.Y ?

> Please also note that pysupport has a nice feature (that IMO should be
> disabled by default, though (I'll file a bug soon), of byte compiling
> modules for officially not supported Python versions (if installed *and*
> maintainer claims it's compatible with that version) - this helps f.e.
> if one installed python2.6 right now (or python2.5 in Etch)

Actually, it’s just that the supported list in python-support is
maintained separately from that of python-defaults. The reason is that
the pyversions script cannot be reliably used from maintainer scripts.
See #396840 for part of the explanation.

--
.'`. Debian 5.0 "Lenny" has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and told
`- me that if you don't install Lenny, he'd melt your brain.
 

Thread Tools




All times are GMT. The time now is 09:09 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org