Joining the team and RFS python-avc

Hi all!
I am looking for sponsorship for my new python module:
python-avc,
   ITP http://bugs.debian.org/
448646,
   mentors http://mentors.debian.net/debian/pool/main/p/python-avc.

I would like to join the team, so I can maintain my package
within the team.

My alioth username is 'fabrizio-guest'.

Thank you in advance for any reply.

--
Regards,
Fabrizio Pollastri


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

Piotr O¿arowski wrote:
> Hi Fabrizio
> 
>> I am looking for sponsorship for my new python
module: python-avc,
>>    ITP http://bugs.debian.org/
448646,
>>    mentors http://mentors.debian.net/debian/pool/main/p/python-avc.

> 
> * remove "Provides: ${python:Provides}" -
architecture independent
> packages don't need it

  OK.

> * you've missed some packages in Depends (for modules:
gtk, qt, PyQt4,
> Tkinter)

Since python-avc is multiplatform, a user will probably use
only one 
among the supported toolkits. So python-avc really needs to
depend from 
them all or it only suggests them?

> 
> I will take a deeper look and upload[1] this package
after work
> 
>> I would like to join the team, so I can maintain my
package within the
>> team.
> 
> I will add you this evening, I don't have my alioth
password ATM
> 
> [1] if ftp-master.debian.org will be back online, there
are some problems
> with it now
> 
> 

--
Cheers,
Fabrizio.


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

>> * you've missed some packages in Depends (for
modules: gtk, qt, PyQt4,
>> Tkinter)
> 
> Since python-avc is multiplatform, a user will probably
use only one
> among the supported toolkits. So python-avc really
needs to depend from
> them all or it only suggests them?

How is decided which toolkit avc uses?
If there's a preferred one, let's call it foo, I'd add
Recommends: foo | bar | fuzz
if not, I'd add them all to suggests.


Cheers,

Bernd

-- 
Bernd Zeimetz
<berndbzed.de>                         <http://bzed.de/>


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

Bernd Zeimetz wrote:
>>> * you've missed some packages in Depends (for
modules: gtk, qt, PyQt4,
>>> Tkinter)
>> Since python-avc is multiplatform, a user will
probably use only one
>> among the supported toolkits. So python-avc really
needs to depend from
>> them all or it only suggests them?
> 
> How is decided which toolkit avc uses?

By user selection: he imports from python-avc the proper
module for the 
desired toolkit, i.e. for gtk 'from avc.avcgtk import *'.

--
Cheers,
Fabrizio.


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

Fabrizio Pollastri wrote:
> Bernd Zeimetz wrote:
>>>> * you've missed some packages in Depends
(for modules: gtk, qt, PyQt4,
>>>> Tkinter)
>>> Since python-avc is multiplatform, a user will
probably use only one
>>> among the supported toolkits. So python-avc
really needs to depend from
>>> them all or it only suggests them?
>>
>> How is decided which toolkit avc uses?
> 
> By user selection: he imports from python-avc the
proper module for the
> desired toolkit, i.e. for gtk 'from avc.avcgtk import
*'.

Then I'd add them all to Suggests:

Cheers,

Bernd

-- 
Bernd Zeimetz
<berndbzed.de>                         <http://bzed.de/>


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

> LE LUNDI 05 NOVEMBRE 2007 à 15:40 +0100, PIOTR
O?AROWSKI A éCRIT :
> > HI FABRIZIO
> > 
> > > I AM LOOKING FOR SPONSORSHIP FOR MY NEW
PYTHON MODULE: PYTHON-AVC,
> > >    ITP HTTP://BUGS.DEBIAN.ORG/448646,
> > >    MENTORS
HTTP://MENTORS.DEBIAN.NET/DEBIAN/POOL/MAIN/P/PYTHON-AVC.
> > 
> > * REMOVE "PROVIDES: ${PYTHON:PROVIDES}"
- ARCHITECTURE INDEPENDENT
                                             
^^^^^^^^^^^^^^^^^^^^^^^^
> > PACKAGES DON'T NEED IT
> 
> OF COURSE THEY DO. WHAT IF A PACKAGE DEPENDS:
PYTHON2.5, PYTHON2.5-AVC?

DEPENDS: PYTHON2.5, PYTHON-AVC (>=NEW_POLICY_VERSION)

JOSS, PYTHON2.5-AVC IS NOT IN NEW POLICY SPIRIT. THINK ABOUT
THIS
SITUATION: FABRIZIO IS UPLOADING THIS PACKAGE NOW, IT
PROVIDES
PYTHON2.4-AVC AND PYTHON2.5-AVC. SOME PACKAGES ARE DEPENDING
ON
PYTHON2.4-AVC AND THEN 2.4 IS REMOVED FROM SUPPORTED PYTHON
VERSIONS.
SHOULD FABRIZIO UPLOAD NEW VERSION JUST BECAUSE 2.4 IS NO
LONGER
SUPPORTED? SHOULD HE UPLOAD NEW VERSION WHEN 2.6 WILL BE
ADDED?
WHAT WITH PACKAGE THAT STILL DEPENDS ON PYTHON2.4-AVC?
WHY DO WE HAVE PYTHON-CENTRAL AND PYTHON-SUPPORT THEN?

PLEASE NOTE THAT I'M TALKING ABOUT ARCHITECTURE
*INDEPENDENT* PACKAGES.
ARCHITECTURE DEPENDENT PACKAGE *HAVE TO* PROVIDE
PYTHONX.Y-MODULE.

FABRIZIO: YOU'RE ADDED, WELCOME IN THE TEAM 
-- 
-=[     PIOTR OZAROWSKI     ]=-
-=[ HTTP://WWW.OZAROWSKI.PL ]=-

Josselin Mouette wrote:
> Hi,
> 
> Le lundi 05 novembre 2007 à 15:40 +0100, Piotr
Ożarowski a écrit :
>> Hi Fabrizio
>>
>>> I am looking for sponsorship for my new python
module: python-avc,
>>>    ITP http://bugs.debian.org/
448646,
>>>    mentors http://mentors.debian.net/debian/pool/main/p/python-avc.

>> * remove "Provides: ${python:Provides}" -
architecture independent
>> packages don't need it
> 
> Of course they do. What if a package Depends:
python2.5, python2.5-avc?

No, they don't.

Please get the _official_ Python Policy fixed and such
requirements
included if you like to have them. Neither the wiki nor
Manoj's home are
the appropriate place for that. Coming up with random
requirements or
undocumented things here is not the way to go.

http://
wiki.debian.org/DebianPython/NewPolicy requires
Provides:
${python:Provides} in two cases:
- if the package used to build pythonX.Y-foo binary
packages
(the package didn't exist before, so I never built such
packages)
- if your package provides public extensions.
(no extensions here - please note that it defines an
extension as .so
file some lines above)


http://ww
w.debian.org/doc/packaging-manuals/python-policy/ch-module_p
ackages.html#s-specifying_versions
says:

2.5 Provides

Provides in packages of the form python-foo must be
specified, if the
package contains an extension for more than one python
version. Provides
should also be added on request of maintainers who depend on
a
non-default python version.

--> Same here - contains an _extension_. An arch:all
package doesn't
ship extensions. The policy defines extensions in the same
way as the
wiki does.

Not to forget that the policy is still outdated.


Even Manoj's start of a new policy document says the same:
http://people.debian.org/~srivasta/manoj-policy/
x316.html#AEN469

Public pure Python modules that have a subset of all python
versions
supported, or for public extensions, the Provides field
indicates which
versions of Python are supported (for which one may import 
the module).
For every version of python supported the package should
provide
pythonX.Y-foo packages. This assumes that the package
correctly depends
on all the appropriate versions of any version specific
module that it
itself requires.

--> We neither have an extension here, nor does it
support a _subset_ of
Python versions.


I'd suggest it's time to replace the more than outdated
policy by
Manoj's new version, which seems to be fine (didn't read
everything yet).


-- 
Bernd Zeimetz
<berndbzed.de>                         <http://bzed.de/>


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

Le mardi 06 novembre 2007 à 00:22 +0100, Bernd Zeimetz a
écrit :
> Please get the _official_ Python Policy fixed and such
requirements
> included if you like to have them. 

The official Python policy is currently unmaintained.

-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender
your code.
`. `'       We will add your hardware and software
distinctiveness to
  `-        our own. Resistance is futile.

LE LUNDI 05 NOVEMBRE 2007 à 23:57 +0100, PIOTR O?AROWSKI A
éCRIT :
> > > * REMOVE "PROVIDES:
${PYTHON:PROVIDES}" - ARCHITECTURE INDEPENDENT
>                                              
^^^^^^^^^^^^^^^^^^^^^^^^
> > > PACKAGES DON'T NEED IT
> > 
> > OF COURSE THEY DO. WHAT IF A PACKAGE DEPENDS:
PYTHON2.5, PYTHON2.5-AVC?
> 
> DEPENDS: PYTHON2.5, PYTHON-AVC
(>=NEW_POLICY_VERSION)

SORRY, BUT THAT DEPENDENCY IS INCORRECT. WHAT IF A LATER
PYTHON-AVC
VERSION STARTS REQUIRING PYTHON >= 2.6 ?

> JOSS, PYTHON2.5-AVC IS NOT IN NEW POLICY SPIRIT. 

THERE IS NO "SPIRIT" IN THE POLICY. THERE ARE ONLY
WAYS TO OBTAIN
CORRECT DEPENDENCIES AND WORKING PACKAGES.

ANYWAY, MY INITIAL REPLY WAS WRONG: PACKAGES DON'T *NEED* TO
PROVIDE
${PYTHON:PROVIDES}. THIS FIELD SHOULD ONLY BE ADDED IF SOME
REVERSE-DEPENDENCIES ARE REQUIRING IT (THE REASON BEING,
WITHOUT
AUTOMATIC ADDITION OF PYTHON2.X-BAR DEPENDENCIES FOR ALL
MODULES/EXTENSIONS YOU DEPEND ON, THESE PROVIDES ARE
INCORRECT). 

> PLEASE NOTE THAT I'M TALKING ABOUT ARCHITECTURE
*INDEPENDENT* PACKAGES.
> ARCHITECTURE DEPENDENT PACKAGE *HAVE TO* PROVIDE
PYTHONX.Y-MODULE.

THERE SHOULDN'T BE ANY DIFFERENCE BETWEEN BOTH WHEN IT COMES
TO
DEPENDENCIES. GENERALLY, ARCHITECTURE: ALL PACKAGES WON'T
NEED THEM, BUT
THIS IS NOT BECAUSE OF THEIR ARCHITECTURE-INDEPENDENCE.

-- 
 .''`.
: :' :      WE ARE DEBIAN.ORG. LOWER YOUR PRICES, SURRENDER
YOUR CODE.
`. `'       WE WILL ADD YOUR HARDWARE AND SOFTWARE
DISTINCTIVENESS TO
  `-        OUR OWN. RESISTANCE IS FUTILE.

Josselin Mouette wrote:
> Le mardi 06 novembre 2007 à 00:22 +0100, Bernd Zeimetz
a écrit :
>> Please get the _official_ Python Policy fixed and
such requirements
>> included if you like to have them. 
> 
> The official Python policy is currently unmaintained.
> 

Then let's maintain it again. We maintain a lot of packages
in a team,
so I can't see a problem to maintain the policy there, too.

-- 
Bernd Zeimetz
<berndbzed.de>                         <http://bzed.de/>


-- 
To UNSUBSCRIBE, email to debian-python-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org