Re: XS-Python-Version vs pyversions

[Tristan Seligmann]

On Tue, Sep 8, 2009 at 6:45 PM, anatoly techtonik  wrote:
> Mailing lists are not documentation. Wiki is some kind of docs, but it
> still bears a high degree of uncertainty.

This is missing the point. The original point of contention was
whether or not certain communication occurred; the mailing list
archives are a record of communication that occurred on the list, and
are thus documentation of what communication occurred. As far as
documentation of policy goes:

> They were documented.  The documentation has bitrotted because consensus was
> abandoned.
>
> It once lived at  - before
> the python policy process degenerated into such an absurd mess that the
> maintainer left Debian entirely.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Scott Kitterman]

On Tue, 8 Sep 2009 19:06:17 +0200 Piotr O
|arowski  wrote:
...
>how about using build dependencies *if* pyversions and XS-P-V are not
>set and removing support of these fields once all packages will
>use the new approach?

Seems reasonable.

Scott K


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Scott Kitterman]

On Tue, 08 Sep 2009 19:19:12 +0200 Josselin Mouette  wrote:
>Le mardi 08 septembre 2009 à 19:06 +0200, Piotr O
|arowski a écrit : 
>> > Since the build-dep approach should have agreement from all the helper
>> > maintainers before it moves forward, I think it would be a good first
>> > step to mark pyversions deprecated (initially in favor of XS-* and
>> > later in favor of the build depends approach) and leave it up to
>> > package maintainers if they care to change in the near term.
>> 
>> how about using build dependencies *if* pyversions and XS-P-V are not
>> set and removing support of these fields once all packages will
>> use the new approach?
>
>I think that s the most efficient approach indeed. For that, we need to
>either: 
>  * patch /usr/bin/pyversions to use them instead 
>  * or introduce a new script that does this, and get cdbs and dh7
>to use it instead

I'm fine with either, but the pyversions approach seems more natural.  It also 
save have to explicity specify the required design in sufficient detail for 
packages using neither debhelper nor CDBS.

Scott K


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Piotr Ożarowski]

[Josselin Mouette, 2009-09-08]
> I think that’s the most efficient approach indeed. For that, we need to
> either: 
>   * patch /usr/bin/pyversions to use them instead 

I will create a patch next week (my TODO list is too long to do it sooner)
and will try to convince Matthias to apply it.
-- 
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-


signature.asc
Description: Digital signature

Re: XS-Python-Version vs pyversions

[Josselin Mouette]

Le mardi 08 septembre 2009 à 19:06 +0200, Piotr Ożarowski a écrit : 
> > Since the build-dep approach should have agreement from all the helper
> > maintainers before it moves forward, I think it would be a good first
> > step to mark pyversions deprecated (initially in favor of XS-* and
> > later in favor of the build depends approach) and leave it up to
> > package maintainers if they care to change in the near term.
> 
> how about using build dependencies *if* pyversions and XS-P-V are not
> set and removing support of these fields once all packages will
> use the new approach?

I think that’s the most efficient approach indeed. For that, we need to
either: 
  * patch /usr/bin/pyversions to use them instead 
  * or introduce a new script that does this, and get cdbs and dh7
to use it instead

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: XS-Python-Version vs pyversions

[Piotr Ożarowski]

[Scott Kitterman, 2009-09-08]
> On Tue, 08 Sep 2009 17:48:18 +0200 Josselin Mouette 
> wrote:
> >> Twas brillig at 16:42:41 08.09.2009 UTC+02 when pi...@debian.org
> >> did gyre and gimble:
> >>  PO> I.e. using build dependencies to determine[1] requested Python
> >>  PO> versions. Joss mentioned it on #debian-python recently so I guess
> >>  PO> he's willing to remove pyversions...
> >
> >I can remove it, but only when all packages using it have stopped doing
> >so. And frankly it sounds better, if we have to migrate them, to migrate
> >them to a new build-dependencies based system rather than migrating them
> >twice.
> 
> Since the build-dep approach should have agreement from all the helper
> maintainers before it moves forward, I think it would be a good first
> step to mark pyversions deprecated (initially in favor of XS-* and
> later in favor of the build depends approach) and leave it up to
> package maintainers if they care to change in the near term.

how about using build dependencies *if* pyversions and XS-P-V are not
set and removing support of these fields once all packages will
use the new approach?
-- 
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-


signature.asc
Description: Digital signature

Re: XS-Python-Version vs pyversions

[anatoly techtonik]

On Tue, Sep 8, 2009 at 1:00 PM, Steve Langasek wrote:
>> Twas brillig at 02:42:09 08.09.2009 UTC-07 when vor...@debian.org did gyre 
>> and gimble:
>
>>  SL> Spare me your ignorant preaching and go read the mailing list
>>  SL> archives.
>
>> Mailing list archives are not documentation.
>
> They're documentation that you're wrong.  Stop wasting my time.

Mailing lists are not documentation. Wiki is some kind of docs, but it
still bears a high degree of uncertainty.

> --
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> Ubuntu Developer                                    http://www.debian.org/
> slanga...@ubuntu.com                                     vor...@debian.org

-- 
anatoly t.
Random Debian User


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Scott Kitterman]

On Tue, 08 Sep 2009 17:48:18 +0200 Josselin Mouette  wrote:
>Le mardi 08 septembre 2009 à 21:50 +0700, Mikhail Gusarov a écrit : 
>> Twas brillig at 16:42:41 08.09.2009 UTC+02 when pi...@debian.org did gyre 
>> and gimble:
>> 
>>  PO> I.e. using build dependencies to determine[1] requested Python
>>  PO> versions. Joss mentioned it on #debian-python recently so I guess
>>  PO> he's willing to remove pyversions...
>
>I can remove it, but only when all packages using it have stopped doing
>so. And frankly it sounds better, if we have to migrate them, to migrate
>them to a new build-dependencies based system rather than migrating them
>twice.

Since the build-dep approach should have agreement from all the helper 
maintainers before it moves forward, I think it would be a good first step to 
mark pyversions deprecated (initially in favor of XS-* and later in favor of 
the build depends approach) and leave it up to package maintainers if they care 
to change in the near term.

>> What about XB-Python-Version, is this field still useful?
>
>The only thing that used it was python-central, and it now stores the
>information on-disk, in /usr/share/pyshared-data/$package. So I think it
>could be removed.

Then (assuming this is verified) XB-* could also be deprecated.

Scott K


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Josselin Mouette]

Le mardi 08 septembre 2009 à 21:50 +0700, Mikhail Gusarov a écrit : 
> Twas brillig at 16:42:41 08.09.2009 UTC+02 when pi...@debian.org did gyre and 
> gimble:
> 
>  PO> I.e. using build dependencies to determine[1] requested Python
>  PO> versions. Joss mentioned it on #debian-python recently so I guess
>  PO> he's willing to remove pyversions...

I can remove it, but only when all packages using it have stopped doing
so. And frankly it sounds better, if we have to migrate them, to migrate
them to a new build-dependencies based system rather than migrating them
twice.

> What about XB-Python-Version, is this field still useful?

The only thing that used it was python-central, and it now stores the
information on-disk, in /usr/share/pyshared-data/$package. So I think it
could be removed.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: XS-Python-Version vs pyversions

[Mikhail Gusarov]

Twas brillig at 16:42:41 08.09.2009 UTC+02 when pi...@debian.org did gyre and 
gimble:

 PO> I.e. using build dependencies to determine[1] requested Python
 PO> versions. Joss mentioned it on #debian-python recently so I guess
 PO> he's willing to remove pyversions...

Sounds good, getting rid of duplicated information.

What about XB-Python-Version, is this field still useful?

-- 
  http://fossarchy.blogspot.com/


pgpjWbruI7sQ0.pgp
Description: PGP signature

Re: XS-Python-Version vs pyversions

[Piotr Ożarowski]

[Scott Kitterman, 2009-09-08]
> Does pyversions offer any real advantages over XS-...?  All things being 
> equal, if both helpers support a common method for this I think we should 
> just use it.

/me (while converting his packages back to python-support) is still
using XS-Python-Version

python-support supports *both* fields and I find XS-Python-Version's
syntax nicer (well, except "current" keyword)


PS Since there's no consensus on my dh_python proposal, how about at
least replacing {XS-Python-Version,pyversions} with what I want to do
there for now? I.e. using build dependencies to determine[1] requested
Python versions. Joss mentioned it on #debian-python recently so I guess
he's willing to remove pyversions...

[1] http://lists.debian.org/debian-python/2009/08/msg6.html
-- 
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-


signature.asc
Description: Digital signature

Re: XS-Python-Version vs pyversions

[Scott Kitterman]

On Tue, 08 Sep 2009 15:52:57 +0200 Josselin Mouette  wrote:
>Le mardi 08 septembre 2009 à 09:35 -0400, Scott Kitterman a écrit : 
>> Does pyversions offer any real advantages over XS-...?  All things being 
>> equal, if both helpers support a common method for this I think we should 
>> just use it.
>
>The advantages are cosmetic. And as already explained, this is an
>irrelevant debate. We should now ought to extract that information from
>build-dependencies instead of adding declarative fields that keep out of
>sync.
>
>This is currently impossible since it would require modifying
>the /usr/bin/pyversions script, which packaging scripts use to look for
>the list of python versions to build for.
>
I think the build depends versus separate control field or pyversions 
discussion ought to be dealt with via some policy mechanism (discussed 
separately).

Since it's just cosmetic, I the we ought to use XS-... across the board as a 
team best practice for people to use regardless of the helper in use.  It's a 
very small step for commonality, but it's probably all we can do right now.

Scott K


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Nicolas Chauvat]

On Tue, Sep 08, 2009 at 09:53:09AM -0400, Scott Kitterman wrote:
> On Tue, 08 Sep 2009 12:21:07 +0200 Bernd Zeimetz  wrote:
> >There was a policy process? 
> 
> Apparently we still need one of these.  Can we work on solving this?  I 
> think having a mechanism to create an actual current, maintained Python 
> policy is a pre-requisite to solving a lot of these problems.

+1

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances  


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Josselin Mouette]

Le mardi 08 septembre 2009 à 09:35 -0400, Scott Kitterman a écrit : 
> Does pyversions offer any real advantages over XS-...?  All things being 
> equal, if both helpers support a common method for this I think we should 
> just use it.

The advantages are cosmetic. And as already explained, this is an
irrelevant debate. We should now ought to extract that information from
build-dependencies instead of adding declarative fields that keep out of
sync.

This is currently impossible since it would require modifying
the /usr/bin/pyversions script, which packaging scripts use to look for
the list of python versions to build for.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: XS-Python-Version vs pyversions

[Scott Kitterman]

On Tue, 08 Sep 2009 12:21:07 +0200 Bernd Zeimetz  wrote:
>There was a policy process? 

Apparently we still need one of these.  Can we work on solving this?  I 
think having a mechanism to create an actual current, maintained Python 
policy is a pre-requisite to solving a lot of these problems.

Scott K


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Scott Kitterman]

On Tue, 08 Sep 2009 11:49:20 +0200 Bernd Zeimetz  wrote:
>Steve Langasek wrote:
>> The XS-Python-Version field was specified as a tool for detecting, 
without
>> having to download and inspect individual source packages, that a given
>> package can be successfully rebuilt for a python transition, to aid the
>> release team in this work.
>
>As mentioned somewhere else in this thread it makes much more sense to 
loog at
>the build-dependencies. Packages which need a special (single) version of 
Python
>are easy to detect on their biuild-dependencies. For the few packages which
>depend on python-all(-.*), although they build modules only for a limited 
number
>of Python versions, it is still a good idea to rebuild them to ensure that 
they
>still build with the tools from the latest version (like pyversions, 
python.mk,
>your $favourite python helper).
>>From the 90 packages in the Python Modules team which use 
debian/pyversions,
>there are only 5 which have the Python versions limited to <<2.5, so 
they'll be
>gone as soon as Python 2.4 is removed.
>So I fail to see a reason why the XS-Foo stuff is necessary.
>
Does pyversions offer any real advantages over XS-...?  All things being 
equal, if both helpers support a common method for this I think we should 
just use it.

Scott K

P. S. Despite most of my packages currently using one helper, I'm not 
dogmatic about it.  I'm mostly sick of all this mess.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Bernd Zeimetz]

Steve Langasek wrote:
> On Tue, Sep 08, 2009 at 04:49:54PM +0700, Mikhail Gusarov wrote:
> 
>> Twas brillig at 02:42:09 08.09.2009 UTC-07 when vor...@debian.org did gyre 
>> and gimble:
> 
>>  SL> Spare me your ignorant preaching and go read the mailing list
>>  SL> archives.
> 
>> Mailing list archives are not documentation.
> 
> They're documentation that you're wrong.  Stop wasting my time.

Oh snap. Come on Steve, the only useful written documentation about the new
Python policy was (is?) a wiki page. Not even the "official" policy is complete.

-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Mikhail Gusarov]

Twas brillig at 03:00:53 08.09.2009 UTC-07 when vor...@debian.org did gyre and 
gimble:

 SL> 

So Steve went here for whining, not for fixing the situation. How sad :(

-- 
  http://fossarchy.blogspot.com/


pgpxrPkrnQu1T.pgp
Description: PGP signature

Re: XS-Python-Version vs pyversions

[Bernd Zeimetz]

Steve Langasek wrote:
> On Tue, Sep 08, 2009 at 03:53:31PM +0700, Mikhail Gusarov wrote:
> 
>> Twas brillig at 20:21:31 07.09.2009 UTC-07 when vor...@debian.org did gyre 
>> and gimble:
> 
>>  >>  SL> They were part of the design that came out of the python
>>  >>  SL> packaging BoF in DebConf 6 that you then proceeded to ignore
>>  >>  SL> entirely.
> 
>>  >> Is this design and rationale written down somewhere? It's hard to
>>  >> follow policy which contains completely opaque requirements.
> 
>>  SL> No, it's pretty much bitrotted away by now
> 
>> Thanks to those who did not communicate ideas outside of the DC
>> attendants.
> 
> Bullshit.  Spare me your ignorant preaching and go read the mailing list
> archives.

Oh yet another BoF where the people taking part started to think they can rule
the rest of the world without talking to it.


>>  SL> thanks to people deciding to discard all the efforts of the session
>>  SL> in question
> 
>> Which were not documented.
> 
> They were documented.  The documentation has bitrotted because consensus was
> abandoned.
> 
> It once lived at  - before
> the python policy process degenerated into such an absurd mess that the
> maintainer left Debian entirely.


There was a policy process? Asking the Python maintainer about the way the
policy is changed the answer was pretty much "it is decided and written by the
Python maintainer, an nobody else". There is no process, there is a one man 
show.


>> Single "why?" document would help to resolve situation much better than
>> endless whining about "bad python-support developers". Just accept the
>> facts that you've failed to communicate ideas behind policy,
> 
> Bullshit.  The python-support maintainer knows the reasons already.  This
> was not a failure of communication, only a failure of collaboration.


Or a 'no I don't implement useless ideas'.

>> reevaluate situation and propose something that is constructive, this will
>> be beneficial for all of us.
> 
> And why would that work any better now than it did three years ago?  If
> anything, the responses in this thread show that the list is far more beset
> with python-support apologists now, who are even less willing to approach
> the problem from a policy perspective and are only interested in defending
> their favorite tool.

The reason why people prefer python-support is easy:
- the upstream author is responsive
- the upstream author fixes bugs in time
- it just works as expected
- it doesn't need such ugly workarounds like "nomove"

That alone are more than enough reasons to to use -central. Its not my fault
that the upstreams of both helpers are not able to collaborate, but if you have
the choice, you choose the better tool, which is python-support now.

-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Steve Langasek]

On Tue, Sep 08, 2009 at 04:49:54PM +0700, Mikhail Gusarov wrote:

> Twas brillig at 02:42:09 08.09.2009 UTC-07 when vor...@debian.org did gyre 
> and gimble:

>  SL> Spare me your ignorant preaching and go read the mailing list
>  SL> archives.

> Mailing list archives are not documentation.

They're documentation that you're wrong.  Stop wasting my time.



-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: XS-Python-Version vs pyversions

[Mikhail Gusarov]

Twas brillig at 02:42:09 08.09.2009 UTC-07 when vor...@debian.org did gyre and 
gimble:

 SL> Spare me your ignorant preaching and go read the mailing list
 SL> archives.

Mailing list archives are not documentation.

 SL> It once lived at  -
 SL> before the python policy process degenerated into such an absurd
 SL> mess that the maintainer left Debian entirely.

Policy did not have any kind of rationale. I read it many times. The
only question was: WHY??

 SL> No, I'm not a dictator; I'm just a member of the Debian Release
 SL> Team who has watched in frustration as the python political
 SL> nonsense has failed for three years to deliver anything that
 SL> actually facilitates python version transitions - which was the
 SL> main reason for drafting a new python policy in the first place.

This is not clear from the policy.

 SL> Thanks for pissing on the release team.

Thanks for beating straw man.

 >> Single "why?" document would help to resolve situation much better than
 >> endless whining about "bad python-support developers". Just accept the
 >> facts that you've failed to communicate ideas behind policy,

 SL> The python-support maintainer knows the reasons already.  This was
 SL> not a failure of communication, only a failure of collaboration.

It would not be accepted in first place if there would be written
rationale behind the policy.

When I first had to chose between the helpers I went with the one which
did not require me to pass magic jumbo-jumbo, and that was
python-support with clearly stated the REASONS for all the
stuff. python-central was the magic: "add this here and don't even try
to ask us why it needs to be here".

 >> reevaluate situation and propose something that is constructive,
 >> this will be beneficial for all of us.

 SL> And why would that work any better now than it did three years ago? 

You've got an experience: unwritten knowledge leads to truely idiotic
situations like current one.

 SL> If anything, the responses in this thread show that the list is far
 SL> more beset with python-support apologists now, who are even less
 SL> willing to approach the problem from a policy perspective and are
 SL> only interested in defending their favorite tool.

I would repeat own words: BULLSHIT. But I don't want to discuss at this
level. I know you're pissed of, but this won't help resolve situation.

-- 
  http://fossarchy.blogspot.com/


pgpW29y87Srsu.pgp
Description: PGP signature

Re: XS-Python-Version vs pyversions

[Bernd Zeimetz]

Steve Langasek wrote:
> The XS-Python-Version field was specified as a tool for detecting, without
> having to download and inspect individual source packages, that a given
> package can be successfully rebuilt for a python transition, to aid the
> release team in this work.

As mentioned somewhere else in this thread it makes much more sense to loog at
the build-dependencies. Packages which need a special (single) version of Python
are easy to detect on their biuild-dependencies. For the few packages which
depend on python-all(-.*), although they build modules only for a limited number
of Python versions, it is still a good idea to rebuild them to ensure that they
still build with the tools from the latest version (like pyversions, python.mk,
your $favourite python helper).
>From the 90 packages in the Python Modules team which use debian/pyversions,
there are only 5 which have the Python versions limited to <<2.5, so they'll be
gone as soon as Python 2.4 is removed.
So I fail to see a reason why the XS-Foo stuff is necessary.

-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Steve Langasek]

On Tue, Sep 08, 2009 at 03:53:31PM +0700, Mikhail Gusarov wrote:

> Twas brillig at 20:21:31 07.09.2009 UTC-07 when vor...@debian.org did gyre 
> and gimble:

>  >>  SL> They were part of the design that came out of the python
>  >>  SL> packaging BoF in DebConf 6 that you then proceeded to ignore
>  >>  SL> entirely.

>  >> Is this design and rationale written down somewhere? It's hard to
>  >> follow policy which contains completely opaque requirements.

>  SL> No, it's pretty much bitrotted away by now

> Thanks to those who did not communicate ideas outside of the DC
> attendants.

Bullshit.  Spare me your ignorant preaching and go read the mailing list
archives.

>  SL> thanks to people deciding to discard all the efforts of the session
>  SL> in question

> Which were not documented.

They were documented.  The documentation has bitrotted because consensus was
abandoned.

It once lived at  - before
the python policy process degenerated into such an absurd mess that the
maintainer left Debian entirely.

>  SL> and unilaterally implement helpers that don't do what was asked
>  SL> for.

> You're not a dictator who has the rights to command what helpers to
> exist, especially if your favorite one is not backed by any written
> rationale.

No, I'm not a dictator; I'm just a member of the Debian Release Team who has
watched in frustration as the python political nonsense has failed for three
years to deliver anything that actually facilitates python version
transitions - which was the main reason for drafting a new python policy in
the first place.

Thanks for pissing on the release team.

> Single "why?" document would help to resolve situation much better than
> endless whining about "bad python-support developers". Just accept the
> facts that you've failed to communicate ideas behind policy,

Bullshit.  The python-support maintainer knows the reasons already.  This
was not a failure of communication, only a failure of collaboration.

> reevaluate situation and propose something that is constructive, this will
> be beneficial for all of us.

And why would that work any better now than it did three years ago?  If
anything, the responses in this thread show that the list is far more beset
with python-support apologists now, who are even less willing to approach
the problem from a policy perspective and are only interested in defending
their favorite tool.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: XS-Python-Version vs pyversions

[Bernd Zeimetz]

Steve Langasek wrote:
> On Sun, Sep 06, 2009 at 07:59:13PM +0200, Luca Falavigna wrote:
>> Il giorno Sun, 6 Sep 2009 19:32:34 +0200
>> Alessandro Dentella  ha scritto:
>>>pyversions: missing XS-Python-Version in control file, fall back to
>>>debian/pyversions
> 
>> It's fine to have debian/pyversions without XS-Python-Version when you
>> use python-support, just ignore this notice.
> 
> FSVO "fine" that includes "completely destroying the value of the python
> policy for the Debian release team".

Please do not even think about talking about the so called Python policy, which
is not maintained at all, does not reflect the current state of packaging, is
missing a lot of information and is far away from reality. Even Manoj managed to
write a much more complete version of the policy out of his own interest.
#447231 is oopen since a long time now

-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Mikhail Gusarov]

Twas brillig at 09:35:04 08.09.2009 UTC+01 when floris.bruynoo...@gmail.com did 
gyre and gimble:

 >> Is this design and rationale written down somewhere? It's hard to
 >> follow policy which contains completely opaque requirements.

 FB> I recall watching a video of that BoF, so it should be possible to
 FB> find that video again if you're keen.

Thanks, I'll have a look, though it hardly can be accepted as a source
of information, but as a source of source of information.

-- 
  http://fossarchy.blogspot.com/


pgpngXiQEEwSf.pgp
Description: PGP signature

Re: XS-Python-Version vs pyversions

[Mikhail Gusarov]

Twas brillig at 20:21:31 07.09.2009 UTC-07 when vor...@debian.org did gyre and 
gimble:

 >>  SL> They were part of the design that came out of the python
 >>  SL> packaging BoF in DebConf 6 that you then proceeded to ignore
 >>  SL> entirely.

 >> Is this design and rationale written down somewhere? It's hard to
 >> follow policy which contains completely opaque requirements.

 SL> No, it's pretty much bitrotted away by now

Thanks to those who did not communicate ideas outside of the DC
attendants.

 SL> thanks to people deciding to discard all the efforts of the session
 SL> in question

Which were not documented.

 SL> and unilaterally implement helpers that don't do what was asked
 SL> for.

You're not a dictator who has the rights to command what helpers to
exist, especially if your favorite one is not backed by any written
rationale.

Single "why?" document would help to resolve situation much better than
endless whining about "bad python-support developers". Just accept the
facts that you've failed to communicate ideas behind policy, reevaluate
situation and propose something that is constructive, this will be
beneficial for all of us.

-- 
  http://fossarchy.blogspot.com/


pgpQRMMduzf0s.pgp
Description: PGP signature

Re: XS-Python-Version vs pyversions

[Josselin Mouette]

Le lundi 07 septembre 2009 à 20:21 -0700, Steve Langasek a écrit : 
> >  SL> They were part of the design that came out of the python packaging
> >  SL> BoF in DebConf 6 that you then proceeded to ignore entirely.

Please don’t bring that topic again. I have spent more than enough time
implementing things that Andreas and you requested specifically, and
that Matthias ignored completely.

> No, it's pretty much bitrotted away by now thanks to people deciding to
> discard all the efforts of the session in question and unilaterally
> implement helpers that don't do what was asked for.

Please stop distorting facts.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: XS-Python-Version vs pyversions

[anatoly techtonik]

On Mon, Sep 7, 2009 at 9:49 PM, Mikhail Gusarov wrote:
>
> Twas brillig at 11:37:50 07.09.2009 UTC-07 when vor...@debian.org did gyre 
> and gimble:
>
>  SL> They were part of the design that came out of the python packaging
>  SL> BoF in DebConf 6 that you then proceeded to ignore entirely.
>
> Is this design and rationale written down somewhere? It's hard to follow
> policy which contains completely opaque requirements.

+1   It is impossible to reverse reasons based on initial statements
like "This is used to track packages during Python transitions, and is
also used by some packaging scripts to automatically generate
appropriate Depends and Provides lines."

What is the process of "tracking packages"? Any examples? Even if
Depends and Provides are automatically generated developer still
supply X-...-Python headers manually, so this add nothing more than
another level of indirection with some bit of uncertainty to
maintainer's mind.

Quiting further from
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions

-- cut here ---
Your control file should also have a line:

 XB-Python-Version: ${python:Versions}
The python:Versions is substituted by the supported Python versions of
the binary package, based on XS-Python-Version. (If you are not using
dh_python you will need to handle this substitution yourself.) The
format of the field XB-Python-Version is the same as the
XS-Python-Version field for packages not containing extensions.
Packages with extensions must list the versions explicitely.
--- cut here ---

It does tell what spell to weave, but does not explain what problem it
is aimed to solve. Is it solely for copying Depends field from source
package to binary?


I do not get some aspects of Python packaging in Debian mostly because
there are many thing that people take for granted (and also because
the lack of time to read out all the stuff). I would be grateful if
you spot any such thing in my point of view and could explain them or
point to the exact place in docs.

Thanks.
-- 
anatoly t.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: XS-Python-Version vs pyversions

[Floris Bruynooghe]

On Tue, Sep 08, 2009 at 01:49:06AM +0700, Mikhail Gusarov wrote:
> 
> Twas brillig at 11:37:50 07.09.2009 UTC-07 when vor...@debian.org did gyre 
> and gimble:
> 
>  SL> They were part of the design that came out of the python packaging
>  SL> BoF in DebConf 6 that you then proceeded to ignore entirely.
> 
> Is this design and rationale written down somewhere? It's hard to follow
> policy which contains completely opaque requirements.

I recall watching a video of that BoF, so it should be possible to
find that video again if you're keen.


Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org