[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 ]=-
Attachment:
pgp169yccLXy8.pgp
Description: PGP signature