Re: debian/pycompat usage?
Hi,
On Fri, 25 Aug 2006, Floris Bruynooghe wrote:
> AIUI debian/pycompat is not needed anymore currently as dh_python has
> enough by having the XS-Python-Version field, while if you are using
> python-support dh_python is not used at all anymore so it doesn't need
> the debian/pycompat anymore either.
>
> Please correct me if I'm wrong. Also the wiki needs updating to
> reflect this, so if no one corrects me I will do that (unless someone
> beats me to it).
You're right. However there's no point in changing that now, until we have
a proper plan to get rid of dh_python completely and replacing it with
another common infrastructure to generate the ${python:*} substitutions.
I tried to propose one but Matthias Klose didn't respond at all and
Josselin Mouette hasn't given his approval for such a common
infrastructure (even if he agreed on the principle the day when he agreed
to keep dh_python as common thing).
See: http://lists.debian.org/debian-python/2006/08/msg00091.html
> Also, fairly unrelated, since pyversions is part of the python package
> should we build-depend on python? I found somewhere that
> build-depending on python-all-dev (>= 2.3.5-11) is sufficient to pull
> in pyversions, is that really the appropriate way though? I would
> prefer to list python directly as dependency instead of indirect.
If you really need python-all-dev, then it's enough, indeed. If you still
want to list explicitely it doesn't hurt.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/pycompat usage?
Le ven 25 août 2006 03:50, Floris Bruynooghe a écrit : > Hello > > I've somewhat lost track of the exact current status of the new > policy. > > AIUI debian/pycompat is not needed anymore currently as dh_python has > enough by having the XS-Python-Version field, while if you are using > python-support dh_python is not used at all anymore so it doesn't > need the debian/pycompat anymore either. > > Please correct me if I'm wrong. Also the wiki needs updating to > reflect this, so if no one corrects me I will do that (unless someone > beats me to it). debian/pycompat is needed if you want dh_python to do the substitution. You also can (atm) use dh_pysupport do it alone, in that case you must not use debian/pycompat, neither dh_python. > Also, fairly unrelated, since pyversions is part of the python > package should we build-depend on python? I found somewhere that > build-depending on python-all-dev (>= 2.3.5-11) is sufficient to pull > in pyversions, is that really the appropriate way though? I would > prefer to list python directly as dependency instead of indirect. it depends. if you build for a pythonX.Y you should just B-D on pythonX.Y-dev, if you build for current on python-dev, if you do a multi-build you should use python-all-dev. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp6dhSCgeDIt.pgp Description: PGP signature
Re: debian/pycompat usage?
On Fri, 25 Aug 2006, Pierre Habouzit wrote: > debian/pycompat is needed if you want dh_python to do the substitution. > You also can (atm) use dh_pysupport do it alone, in that case you must > not use debian/pycompat, neither dh_python. If someone really wants to use dh_pysupport to generate the dependencies, it would be better with an expliciti "-d" option instead of relying on the absence of a file. The interface is clearer for everybody until we have again decided the proper way of handling everything without dh_python. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urwid (updated package)
On Thu, Aug 24, 2006, Ian Ward wrote: > http://mentors.debian.net/debian/pool/main/u/urwid/urwid_0.9.6-1.dsc Uploaded. Would be nice to have an upstream ChangeLog. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/pycompat usage?
Le vendredi 25 août 2006 à 09:41 +0200, Raphael Hertzog a écrit :
> Hi,
>
> On Fri, 25 Aug 2006, Floris Bruynooghe wrote:
> > AIUI debian/pycompat is not needed anymore currently as dh_python has
> > enough by having the XS-Python-Version field, while if you are using
> > python-support dh_python is not used at all anymore so it doesn't need
> > the debian/pycompat anymore either.
> >
> > Please correct me if I'm wrong. Also the wiki needs updating to
> > reflect this, so if no one corrects me I will do that (unless someone
> > beats me to it).
>
> You're right. However there's no point in changing that now, until we have
> a proper plan to get rid of dh_python completely and replacing it with
> another common infrastructure to generate the ${python:*} substitutions.
> I tried to propose one but Matthias Klose didn't respond at all and
> Josselin Mouette hasn't given his approval for such a common
> infrastructure (even if he agreed on the principle the day when he agreed
> to keep dh_python as common thing).
I will not use the common infrastructure until it gets seriously fixed.
-rwxr-xr-x 1 root root 11709 2006-08-10 13:30 /usr/bin/dh_pysupport
-rwxr-xr-x 1 root root 24020 2006-07-10 14:14 /usr/bin/dh_python
This means twice as much code without handling all cases dh_pysupport
currently handles (including compatibility with the "old" dh_python).
Currently, with a relatively small amount of work, we could completely
replace dh_python with dh_pysupport without breaking compatibility for
older packages, and I believe this would be the sanest approach. However
Joey Hess doesn't want this to happen as long as python-central exists,
and I fear that Matthias Klose will refuse anything that would bring us
out of this horrible "new policy" mess (despite the proof that 80% of
this "policy" thing is nothing but useless complication for package
maintainers).
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: debian/pycompat usage?
On Fri, Aug 25, 2006 at 02:43:29PM +0200, Josselin Mouette wrote:
> Le vendredi 25 août 2006 à 09:41 +0200, Raphael Hertzog a écrit :
> > On Fri, 25 Aug 2006, Floris Bruynooghe wrote:
> > > AIUI debian/pycompat is not needed anymore currently as dh_python has
> > > enough by having the XS-Python-Version field, while if you are using
> > > python-support dh_python is not used at all anymore so it doesn't need
> > > the debian/pycompat anymore either.
> > > Please correct me if I'm wrong. Also the wiki needs updating to
> > > reflect this, so if no one corrects me I will do that (unless someone
> > > beats me to it).
> > You're right. However there's no point in changing that now, until we have
> > a proper plan to get rid of dh_python completely and replacing it with
> > another common infrastructure to generate the ${python:*} substitutions.
> > I tried to propose one but Matthias Klose didn't respond at all and
> > Josselin Mouette hasn't given his approval for such a common
> > infrastructure (even if he agreed on the principle the day when he agreed
> > to keep dh_python as common thing).
> I will not use the common infrastructure until it gets seriously fixed.
> -rwxr-xr-x 1 root root 11709 2006-08-10 13:30 /usr/bin/dh_pysupport
> -rwxr-xr-x 1 root root 24020 2006-07-10 14:14 /usr/bin/dh_python
> This means twice as much code without handling all cases dh_pysupport
> currently handles (including compatibility with the "old" dh_python).
> Currently, with a relatively small amount of work, we could completely
> replace dh_python with dh_pysupport without breaking compatibility for
> older packages, and I believe this would be the sanest approach. However
> Joey Hess doesn't want this to happen as long as python-central exists,
> and I fear that Matthias Klose will refuse anything that would bring us
> out of this horrible "new policy" mess (despite the proof that 80% of
> this "policy" thing is nothing but useless complication for package
> maintainers).
I object to basing future work exclusively on dh_pysupport as long as it
implements your unilateral decision to abandon the XB-Python-Version field
and deprecate the XS-Python-Version without offering any alternative
suitable for mass-detection of binNMU candidates.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/pycompat usage?
Le vendredi 25 août 2006 à 13:09 -0700, Steve Langasek a écrit : > I object to basing future work exclusively on dh_pysupport as long as it > implements your unilateral decision to abandon the XB-Python-Version field > and deprecate the XS-Python-Version This decision was not unilateral, sorry. As long as these fields don't even have clear semantics, implementing them is, at best, useless. > without offering any alternative > suitable for mass-detection of binNMU candidates. What if I provide you with a script that does the same without the fields? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: debian/pycompat usage?
Le ven 25 août 2006 22:26, Josselin Mouette a écrit : > Le vendredi 25 août 2006 à 13:09 -0700, Steve Langasek a écrit : > > I object to basing future work exclusively on dh_pysupport as long > > as it implements your unilateral decision to abandon the > > XB-Python-Version field and deprecate the XS-Python-Version > > This decision was not unilateral, sorry. As long as these fields > don't even have clear semantics, implementing them is, at best, > useless. > > > without offering any alternative > > suitable for mass-detection of binNMU candidates. > > What if I provide you with a script that does the same without the > fields? I will do that, I've promised it. I've had a hell of a week, but I will work on that this week. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpCVhSaXbefV.pgp Description: PGP signature
Re: debian/pycompat usage?
Le sam 26 août 2006 00:39, Pierre Habouzit a écrit : > Le ven 25 août 2006 22:26, Josselin Mouette a écrit : > > Le vendredi 25 août 2006 à 13:09 -0700, Steve Langasek a écrit : > > > I object to basing future work exclusively on dh_pysupport as > > > long as it implements your unilateral decision to abandon the > > > XB-Python-Version field and deprecate the XS-Python-Version > > > > This decision was not unilateral, sorry. As long as these fields > > don't even have clear semantics, implementing them is, at best, > > useless. > > > > > without offering any alternative > > > suitable for mass-detection of binNMU candidates. > > > > What if I provide you with a script that does the same without the > > fields? > > I will do that, I've promised it. I've had a hell of a week, but I > will work on that this week. week-end obviously sorry. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpXopAAE8GvB.pgp Description: PGP signature
Re: debian/pycompat usage?
On Fri, Aug 25, 2006 at 10:26:54PM +0200, Josselin Mouette wrote: > Le vendredi 25 août 2006 à 13:09 -0700, Steve Langasek a écrit : > > I object to basing future work exclusively on dh_pysupport as long as it > > implements your unilateral decision to abandon the XB-Python-Version field > > and deprecate the XS-Python-Version > This decision was not unilateral, sorry. It was a decision, made by you as python-support maintainer, in direct contradiction to what Matthias and I had discussed before DebConf and the conclusions of the DebConf python BoF, without any consideration given to the original goal of these fields. That's unilateral. > As long as these fields don't even have clear semantics, implementing > them is, at best, useless. So, why has there been no discussion about the problems with the semantics and how they might be *fixed*? > > without offering any alternative > > suitable for mass-detection of binNMU candidates. > What if I provide you with a script that does the same without the > fields? So I get to unpack a couple hundred source packages on ftp-master/bugs.d.o for each transition in order to inspect debian/pyversions in each one (and who knows what else at this point) to identify the packages that are binNMUable, instead of being able to get the same information out of Packages+Sources? I don't find this plan particularly impressive. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
