Re: [Mageia-dev] Python packaging policy
Hi Joseph, On Thu, 13 Dec 2012 14:53:04 +0800 Joseph Wang joequ...@gmail.com wrote: Looking over this page: https://wiki.mageia.org/en/Python_policy * python-pyp2rpm is undergoing review right now. Once it's in cauldron, I'd like to point to that package as something that packagers you should use to get a first draft of a spec file, I've been working with the Fedora people so that it will do both fedora and mageia naming conventions. Sounds good. Does it support building for both Python 2.x and Python 3.x (in case both are supported)? * I'd like to add a rule (which is followed by current packages) that the prefix py should generally be removed from a package name. For example pyopencl should be called python-opencl. This is the current convention for packages in mageia. I'm OK with it either way. * Also for grouping. I'd like to add a rule that Development/Python is intended for packages which provide general development libraries for python, and if the library fits into an obvious other category (i.e. python routines for cosmology calculations) those should go into the other category. Sounds good. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Rethinking CPAN - http://shlom.in/rethinking-cpan mst I find it’s usually safe to assume that whatever shlomif’s doing, there isn’t a good reason for it. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: [Mageia-dev] Python packaging policy
Le 13/12/2012 09:00, Shlomi Fish a écrit : * Also for grouping. I'd like to add a rule that Development/Python is intended for packages which provide general development libraries for python, and if the library fits into an obvious other category (i.e. python routines for cosmology calculations) those should go into the other category. What is the interest ? The only usage of rpm group is in package installation GUI, mostly used by end-users. They don't care of development bricks, they are generally interested by ready-to-user software (applications) only. Don't throw useless effort in sorting python libraries about their purpose, their nature is enough. -- BOFH excuse #253: We've run out of licenses
Re: [Mageia-dev] Python packaging policy
Hi, Le 13/12/2012 09:00, Shlomi Fish a écrit : Hi Joseph, On Thu, 13 Dec 2012 14:53:04 +0800 Joseph Wangjoequ...@gmail.com wrote: [...] * I'd like to add a rule (which is followed by current packages) that the prefix py should generally be removed from a package name. For example pyopencl should be called python-opencl. This is the current convention for packages in mageia. I'm OK with it either way. I disagree on that point: software and libraries names are choose by the developers. Who are we to change them ? Adding python- at the beginning of the package name for our own organization is one thing, changing the name is another. And our policy only talk about upstream names containing the complete word python, not just py. Claire
Re: [Mageia-dev] Python packaging policy
On Thursday 13. December 2012 15.24, Claire REVILLET wrote: I disagree on that point: software and libraries names are choose by the developers. Who are we to change them ? Adding python- at the beginning of the package name for our own organization is one thing, changing the name is another. I agree with Claire. I had the same reaction when reading the suggestion. It's a Bad idea. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Python packaging policy
Le 13/12/2012 15:24, Claire REVILLET a écrit : Hi, Le 13/12/2012 09:00, Shlomi Fish a écrit : Hi Joseph, On Thu, 13 Dec 2012 14:53:04 +0800 Joseph Wangjoequ...@gmail.com wrote: [...] * I'd like to add a rule (which is followed by current packages) that the prefix py should generally be removed from a package name. For example pyopencl should be called python-opencl. This is the current convention for packages in mageia. I'm OK with it either way. I disagree on that point: software and libraries names are choose by the developers. Who are we to change them ? A free software distribution, whose part of the added value is overall consistency. Which is out of scope of individual software authors by definition. And the current issue is just about the *package* name, not exactly the software name. Remember when 'thunderbird' was distributed as 'mozilla-thunderbird' ? And just to compare it with other similar practices: - we already normalize perl version numbers, for sorting purpose - we already force lowercase package naming - we already modify software setup, to achieve FHS compliance - we already modify package behaviour, to prevent automatic upgrade, for instance The two latest ones seems far most invasive IMHO than just shipping pycups in a package called 'python-cups' rather than 'python-pycups'. -- BOFH excuse #32: techtonic stress
Re: [Mageia-dev] Python packaging policy
Le 13/12/2012 15:43, Guillaume Rousse a écrit : Le 13/12/2012 15:24, Claire REVILLET a écrit : Hi, Le 13/12/2012 09:00, Shlomi Fish a écrit : Hi Joseph, On Thu, 13 Dec 2012 14:53:04 +0800 Joseph Wangjoequ...@gmail.com wrote: [...] * I'd like to add a rule (which is followed by current packages) that the prefix py should generally be removed from a package name. For example pyopencl should be called python-opencl. This is the current convention for packages in mageia. I'm OK with it either way. I disagree on that point: software and libraries names are choose by the developers. Who are we to change them ? A free software distribution, whose part of the added value is overall consistency. Which is out of scope of individual software authors by definition. And the current issue is just about the *package* name, not exactly the software name. Remember when 'thunderbird' was distributed as 'mozilla-thunderbird' ? And just to compare it with other similar practices: - we already normalize perl version numbers, for sorting purpose - we already force lowercase package naming - we already modify software setup, to achieve FHS compliance - we already modify package behaviour, to prevent automatic upgrade, for instance The two latest ones seems far most invasive IMHO than just shipping pycups in a package called 'python-cups' rather than 'python-pycups'. I understand your point, but i fear collisions between package names: (this is not a true example, i can't find one just now) Imagine it exists toto and pytoto in the Python Package Index. It can happen just because some people don't feel the need to add py in the module name as it's already written in python and it's in the Python package index... which seems sensible. Imagine pytoto is imported first with python-toto name for the package. How should i name the package for toto ? We can rename the first one into python-pytoto and import the second with python-toto, but we have to take care of the packages with BR or R on the first one. And it will brake the new policy rule. my 2 cents. Claire
Re: [Mageia-dev] Python packaging policy
Claire REVILLET a écrit : Hi, Le 13/12/2012 09:00, Shlomi Fish a écrit : Hi Joseph, On Thu, 13 Dec 2012 14:53:04 +0800 Joseph Wangjoequ...@gmail.com wrote: [...] * I'd like to add a rule (which is followed by current packages) that the prefix py should generally be removed from a package name. For example pyopencl should be called python-opencl. This is the current convention for packages in mageia. I'm OK with it either way. I disagree on that point: software and libraries names are choose by the developers. Who are we to change them ? Adding python- at the beginning of the package name for our own organization is one thing, changing the name is another. And our policy only talk about upstream names containing the complete word python, not just py. Claire A package name is not a software name... and we have already some packages whose the name is not the same as in other distributions for reasons that belong to our and their organisation : look at JACK (Jack Audio Connection Kit) for instance - opensuse has a rpm simply called jack - Mandriva and Mageia need to name it jackit (because an other software, to rip cd, was already provided in a rpm called jack) - Debian and Ubuntu name their deb jackd or jackd1 (Debian too already used the name jack for the package installing the same cd ripper as Mandrake) - fedora and slackware call the rpm jack-audio-connection-kit (with lowercase...) Those distibutions have their coherency their needs : it's difficult to standardise the packages names for all the distributions because these names have an historical origin ! You can complain ... but that is how it is... For a distribution the need is coherence for its own packagers My two drachmes Philippe
Re: [Mageia-dev] Python packaging policy
On Thu, 13 Dec 2012 14:53:04 +0800 Joseph Wang joequ...@gmail.com wrote: Looking over this page: https://wiki.mageia.org/en/Python_policy * python-pyp2rpm is undergoing review right now. Once it's in cauldron, I'd like to point to that package as something that packagers you should use to get a first draft of a spec file, I've been working with the Fedora people so that it will do both fedora and mageia naming conventions. Will this solve https://bugs.mageia.org/show_bug.cgi?id=3348 ? (which dates back to https://qa.mandriva.com/show_bug.cgi?id=50484 ) Regards Antoine.
Re: [Mageia-dev] Python packaging policy
On 13/12/12 06:53, Joseph Wang wrote:
Looking over this page:
https://wiki.mageia.org/en/Python_policy
* I'd like to add a rule (which is followed by current packages) that
the prefix py should
generally be removed from a package name. For example pyopencl should be called
python-opencl. This is the current convention for packages in mageia.
I think it's too strong. There will necessarily be exceptions, like pypes.
For the package names, I can give you my experience as ocaml packager.
Our policy is roughly the same as for python:
- executables keep their upstream names (ex. js_of_ocaml, camlp5, ...)
- libraries take the 'ocaml-' prefix followed by the upstream name as
much as possible (since these upstream names are known). It leads to
packages like ocaml-ocamlgraph or ocaml-ocamlnet since ocamlgraph and
ocamlnet are well-known libs in the community. However when the library
is just a wrapper for a well-known C library, we drop extra ocaml
prefixes or suffixes (ex: upstream sqlite3-ocaml becomes ocaml-sqlite3).
So overall, no policy should be too strict: the need for uniformity
should not make it too hard for users!
* Also for grouping. I'd like to add a rule that Development/Python
is intended for packages
which provide general development libraries for python, and if the
library fits into an obvious
other category (i.e. python routines for cosmology calculations) those
should go into the
other category.
I don't really agree. The current group policy is the following:
- if it's an application/data - in the corresponding group.
- if it's a library for development - in Development/%{the language}.
- if it's a library not meant for anyone to install independently
- in System/Libraries.
I'm not sure users would find a benefit to have python for cosmology in
the Astronomy section and python for Maths in the Maths section and so on.
What I would encourage you to do however is to create a cosmology wiki
page that describes all the cosmology-features of Mageia.
Best,
--
Malo
Re: [Mageia-dev] Python Packaging Policy
2011/7/16 Michael Scherer m...@zarb.org: Either 2 rpms with the same source, or 1 rpm that generate 2 sub rpms. I would rather use 2 separate rpms, as this seems to be easier. I see, so really treating python2 and python 3 as 2 differents languages why not, that will increase the number of rpms ie python-sqlalchemy and python3-sqlalchemy
Re: [Mageia-dev] Python Packaging Policy
Le mercredi 13 juillet 2011 à 09:51 +0200, philippe makowski a écrit : 2011/7/13 Michael scherer m...@zarb.org: I would be in favor of treating python2 and python 3 as 2 differents languages. The rational is that : - we cannot garantee to have support for both - we will likely have some module who would be updated only on python 3 sooner or later - we will need to do upgrade of package at different time, since both python2 and python3 are released at different time. So rather than a complex scheme that will confuse packagers, just consider they are separate, and use the almost same policy ( with s/python/python3/ ) And how do you manage package that support both P2 and P3 ? (same source) Either 2 rpms with the same source, or 1 rpm that generate 2 sub rpms. I would rather use 2 separate rpms, as this seems to be easier. -- Michael Scherer
Re: [Mageia-dev] Python Packaging Policy
2011/7/13 Michael scherer m...@zarb.org: I would be in favor of treating python2 and python 3 as 2 differents languages. The rational is that : - we cannot garantee to have support for both - we will likely have some module who would be updated only on python 3 sooner or later - we will need to do upgrade of package at different time, since both python2 and python3 are released at different time. So rather than a complex scheme that will confuse packagers, just consider they are separate, and use the almost same policy ( with s/python/python3/ ) And how do you manage package that support both P2 and P3 ? (same source) Regarding a review of all package, that sound like daunting task :/ yes, but do you see another solution ? we can have a priority list
Re: [Mageia-dev] Python Packaging Policy
philippe makowski a écrit : 2011/7/13 Michael schererm...@zarb.org: I would be in favor of treating python2 and python 3 as 2 differents languages. The rational is that : - we cannot garantee to have support for both - we will likely have some module who would be updated only on python 3 sooner or later - we will need to do upgrade of package at different time, since both python2 and python3 are released at different time. So rather than a complex scheme that will confuse packagers, just consider they are separate, and use the almost same policy ( with s/python/python3/ ) And how do you manage package that support both P2 and P3 ? (same source) If we use misc's approach, we could minimize the urgency of the conversion. If upstream supports both, we could either add a virtual provides in P2 and P3 for that (to be used only by such packages), or support just P3 (or maybe just P2). I don't know which is best, but I'd still like to help out. Regarding a review of all package, that sound like daunting task :/ yes, but do you see another solution ? we can have a priority list -- André
Re: [Mageia-dev] Python Packaging Policy
philippe makowski a écrit : Hi, remember this first draft (http://mageia.org/wiki/doku.php?id=python_policy) that is still a draft now we have also Python3 so we really need to write our policy I see mainly two majors points : 1/ pyc, pyo management 2/ having Python2 and Python3 about 1/ : it seems that the best would be to package only py (smallest packages) and having triggers on install and on remove to manage pyc and pyo (That's in fact the Debian way (http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-byte_compilation)) if we go this way, we need someone to write triggers and people to review all Python packages (I'm ok to work on that review, for triggers, I have no clue on how to do, but may be that with some help I could try) +1 (Although I don't have any idea how to do it yet either, but would be willing to try with some help, as well.) about 2/ : again we have to review all Python packages to see if they run under Python3 or not and to package them for Python2 and Python3 (I'm ok to work on that review) may be that the Fedora policy can help us for that ?: http://fedoraproject.org/wiki/Packaging/Python I think it would be very useful to have coexisting python2 3 (like fedora). -- André
Re: [Mageia-dev] Python Packaging Policy
2011/1/19 Michael scherer m...@zarb.org: Because that would 1) requires a patch to rpm that we do not have or 2) patch all python packages to had %ghost on all *.pyc, and do a compilation of *pyc ( the 2nd part is easy, the first one is slightly harder to automate ) 3) do not care about file tracking, but that's unclean. Do not get me wrong, I think that's the way forward, but that's not applicable in a few days. of course Can we forget for a little Mandriva and talk about Mageia ? I mean, we are before the alpha stage, so it's time to think about what the future can be did you read the OpenSuse policy ? http://en.opensuse.org/openSUSE:Packaging_Python of course the best solution would be be to put into the rpm only *.py, bitcompilling them at install and trac *.pyc and *.pyo as %ghost but it seems that neither Fedora, neither OpenSuse have problem to package bitcompiled files (the %fdupes OpenSuse solution seems not bad) or can we patch distutils/command/install.py even more than OpenSuse (https://build.opensuse.org/package/view_file?file=python-distutils-rpm-8.patchpackage=pythonproject=home%3Acoolo%3Abranches%3AopenSUSE%3AFactorysrcmd5=25a3587ace933a14ae62edfc4cd927b7) did, to generate a rpm-compatible format that would manage %ghost ?
Re: [Mageia-dev] Python Packaging Policy
On Wed, 19 Jan 2011 08:25:23 +0100 Michael scherer m...@zarb.org wrote: I'm not sure about twice the work: you don't need to track twice the software releases (except for the interpreter itself), or twice the upstream patches, etc. Well, if we handle this like 2 separates languages, that mean 2 separates rpms for each modules. Or we should be clever when generating 1 rpm to have the modules for both python 3 and python 2 generated ( Except when the developper did choose to have separate tarball or code base ) Having one rpm that produces 2 modules also mean that we will rebuild all modules for python3 and all for python2, and I know that for example Buchan will not like the extranous trafic it would generate. Well AFAIK some other distros (not Debian and Ubuntu which have a more complicated system) have separate packages per interpreter version (python2.4-twisted, python2.6-twisted, etc.). But you can put all versions in a single package too. I see no hard reason against that. Regards Antoine.
Re: [Mageia-dev] Python Packaging Policy
On Tue, Jan 18, 2011 at 08:51:26PM +0100, Antoine Pitrou wrote: On Mon, 17 Jan 2011 09:21:56 +0100 Michael scherer m...@zarb.org wrote: There is also the issue on bytecompilation ( https://qa.mandriva.com/show_bug.cgi?id=50484 ). I have exposed there the various problem, and apart from explaining that the solution I chosed was not better than the other, no one gave a compeling argument into one or the others alternatives. That depends how compelling you expect the argument to be :) The current situation is clearly not satisfactory. I agree that the solution is not perfect for everybody, and if I had one that would not be without problem, I would have adopted it. The solution of generating bytecode at install time looks fine. I am not an RPM specialist though, but if you have non-RPM specific questions feel free to ask them, I'd be glad to answer. Well, that's not satisfying from a rpm pov, unfortunately. But with some patchs, that the one that I would use, yes. until that, i prefer know documented breakage, than new undocumented breakage. (ie, shadok proverb, if you want to have less unhappy people, just hit always the same ). Finally, a vast part of the policy is handling 2to3, a topic that we didn't discuss at all, and I would not be confortable to adopt it without first looking at it and discussing it. What is the issue with handling 2to3? It's a developer tool and certainly shouldn't be invoked at install time if that's what you are asking. Generally, I don't think you (as a packager) have to invoke 2to3 manually at all. If 2to3 is part of the packaged software's build process, then their setup.py will probably invoke it automatically with the right options. I as more speaking of the transition from pyton 2 to python 3. I think the easiest on a policy point of view is to handle this like 2 separate languages, but that mean twice the work. And so we should at least try to do better ( not sure that we can, of course ). -- Michael Scherer Regards Antoine.
Re: [Mageia-dev] Python Packaging Policy
On Wed, 19 Jan 2011 00:55:40 +0100 Michael scherer m...@zarb.org wrote: The solution of generating bytecode at install time looks fine. I am not an RPM specialist though, but if you have non-RPM specific questions feel free to ask them, I'd be glad to answer. Well, that's not satisfying from a rpm pov, unfortunately. Can you explain why it isn't? I'm sure other packages generate stuff at install-time, right? Also, the list of files is well-known (it's everything named *.py that goes somewhere inside /usr/lib/pythonXXX/). What is the issue with handling 2to3? It's a developer tool and certainly shouldn't be invoked at install time if that's what you are asking. Generally, I don't think you (as a packager) have to invoke 2to3 manually at all. If 2to3 is part of the packaged software's build process, then their setup.py will probably invoke it automatically with the right options. I as more speaking of the transition from pyton 2 to python 3. I think the easiest on a policy point of view is to handle this like 2 separate languages, but that mean twice the work. And so we should at least try to do better ( not sure that we can, of course ). Handling them as two separate languages looks indeed like the right thing to do, IMO. In any case, as I said, you shouldn't be the one wondering about 2to3. Upstream developers do, if that's the conversion method they chose for their project. I'm not sure about twice the work: you don't need to track twice the software releases (except for the interpreter itself), or twice the upstream patches, etc. Regards Antoine.
Re: [Mageia-dev] Python Packaging Policy
On Wed, Jan 19, 2011 at 02:07:18AM +0100, Antoine Pitrou wrote: On Wed, 19 Jan 2011 00:55:40 +0100 Michael scherer m...@zarb.org wrote: The solution of generating bytecode at install time looks fine. I am not an RPM specialist though, but if you have non-RPM specific questions feel free to ask them, I'd be glad to answer. Well, that's not satisfying from a rpm pov, unfortunately. Can you explain why it isn't? I'm sure other packages generate stuff at install-time, right? Also, the list of files is well-known (it's everything named *.py that goes somewhere inside /usr/lib/pythonXXX/). Because that would 1) requires a patch to rpm that we do not have or 2) patch all python packages to had %ghost on all *.pyc, and do a compilation of *pyc ( the 2nd part is easy, the first one is slightly harder to automate ) 3) do not care about file tracking, but that's unclean. Do not get me wrong, I think that's the way forward, but that's not applicable in a few days. And I cannot think of a rpm generating stuff at install time that do not requires specific intervention in the spec. Usually, we have packages that register themself in a dynamic list ( man, info, .desktop ), or that trigger symlink ( updates-alternatives ) , and those symlink are not tracked by rpm, and that's a suboptimal solution ( ie, you cannot do a research by file name, etc ) What is the issue with handling 2to3? It's a developer tool and certainly shouldn't be invoked at install time if that's what you are asking. Generally, I don't think you (as a packager) have to invoke 2to3 manually at all. If 2to3 is part of the packaged software's build process, then their setup.py will probably invoke it automatically with the right options. I as more speaking of the transition from pyton 2 to python 3. I think the easiest on a policy point of view is to handle this like 2 separate languages, but that mean twice the work. And so we should at least try to do better ( not sure that we can, of course ). Handling them as two separate languages looks indeed like the right thing to do, IMO. In any case, as I said, you shouldn't be the one wondering about 2to3. Upstream developers do, if that's the conversion method they chose for their project. Well, I was not clear, when i said 2to3, i didn't mean't the tools at all. Rather the fact we have to handle the migration, my sentences was poorly worded. I'm not sure about twice the work: you don't need to track twice the software releases (except for the interpreter itself), or twice the upstream patches, etc. Well, if we handle this like 2 separates languages, that mean 2 separates rpms for each modules. Or we should be clever when generating 1 rpm to have the modules for both python 3 and python 2 generated ( Except when the developper did choose to have separate tarball or code base ) Having one rpm that produces 2 modules also mean that we will rebuild all modules for python3 and all for python2, and I know that for example Buchan will not like the extranous trafic it would generate. So IMHO, there is various things to discuss. -- Michael Scherer
Re: [Mageia-dev] Python Packaging Policy
On Sun, Jan 16, 2011 at 06:15:52PM +0100, philippe makowski wrote: Hi, I though that I can find more time to work on this week end, but unfortunately it was not the case. The Mandriva doc is really not a good starter (http://wiki.mandriva.com/en/Python_packaging_policy) That's just a draft, but as the one that wrote the draft, could I know what is wrong with what was written so far ? so I propose to use the Fedora one (http://fedoraproject.org/wiki/Packaging:Python) with some cleaning. Can we provide same macros as in In Fedora 13 and greater ? Do you see any major problem with the Fedora policy ? First they make plan for having more than one version of python, something that I always told I will not do since no one stepped to do much to help on the transition. In short, as long the python team will in practice be only me ( and in practice, I mean people who effectivly commit ), we will have only 1 supported version of the stack. ( I consider python 3 to be a different language, because of the source level incompatibility ). There is also the issue on bytecompilation ( https://qa.mandriva.com/show_bug.cgi?id=50484 ). I have exposed there the various problem, and apart from explaining that the solution I chosed was not better than the other, no one gave a compeling argument into one or the others alternatives. Finally, a vast part of the policy is handling 2to3, a topic that we didn't discuss at all, and I would not be confortable to adopt it without first looking at it and discussing it. Not to mention that our policy draft speak of thing they do not include ( like naming policy, for a start ). -- Michael Scherer
Re: [Mageia-dev] Python Packaging Policy
2011/1/17 Michael scherer m...@zarb.org: On Sun, Jan 16, 2011 at 06:15:52PM +0100, philippe makowski wrote: Hi, I though that I can find more time to work on this week end, but unfortunately it was not the case. The Mandriva doc is really not a good starter (http://wiki.mandriva.com/en/Python_packaging_policy) That's just a draft, but as the one that wrote the draft, could I know what is wrong with what was written so far ? nothing except it is just a draft ;) so I propose to use the Fedora one (http://fedoraproject.org/wiki/Packaging:Python) with some cleaning. Can we provide same macros as in In Fedora 13 and greater ? Do you see any major problem with the Fedora policy ? First they make plan for having more than one version of python, something that I always told I will not do since no one stepped to do much to help on the transition. In short, as long the python team will in practice be only me ( and in practice, I mean people who effectivly commit ), we will have only 1 supported version of the stack. ( I consider python 3 to be a different language, because of the source level incompatibility ). There is also the issue on bytecompilation ( https://qa.mandriva.com/show_bug.cgi?id=50484 ). I have exposed there the various problem, and apart from explaining that the solution I chosed was not better than the other, no one gave a compeling argument into one or the others alternatives. Finally, a vast part of the policy is handling 2to3, a topic that we didn't discuss at all, and I would not be confortable to adopt it without first looking at it and discussing it. Not to mention that our policy draft speak of thing they do not include ( like naming policy, for a start ). No problem, I understand perfectly so let start with the Mandriva draft
Re: [Mageia-dev] Python Packaging Policy
Le lundi 17 janvier 2011 à 21:03 +0100, philippe makowski a écrit : 2011/1/17 Michael scherer m...@zarb.org: On Sun, Jan 16, 2011 at 06:15:52PM +0100, philippe makowski wrote: Hi, I though that I can find more time to work on this week end, but unfortunately it was not the case. The Mandriva doc is really not a good starter (http://wiki.mandriva.com/en/Python_packaging_policy) That's just a draft, but as the one that wrote the draft, could I know what is wrong with what was written so far ? nothing except it is just a draft ;) Well, i just didn't think i had the authority to impose it, nor much time to discuss it, so I never removed the draft label. so I propose to use the Fedora one (http://fedoraproject.org/wiki/Packaging:Python) with some cleaning. Can we provide same macros as in In Fedora 13 and greater ? Do you see any major problem with the Fedora policy ? First they make plan for having more than one version of python, something that I always told I will not do since no one stepped to do much to help on the transition. In short, as long the python team will in practice be only me ( and in practice, I mean people who effectivly commit ), we will have only 1 supported version of the stack. ( I consider python 3 to be a different language, because of the source level incompatibility ). There is also the issue on bytecompilation ( https://qa.mandriva.com/show_bug.cgi?id=50484 ). I have exposed there the various problem, and apart from explaining that the solution I chosed was not better than the other, no one gave a compeling argument into one or the others alternatives. Finally, a vast part of the policy is handling 2to3, a topic that we didn't discuss at all, and I would not be confortable to adopt it without first looking at it and discussing it. Not to mention that our policy draft speak of thing they do not include ( like naming policy, for a start ). No problem, I understand perfectly so let start with the Mandriva draft We can merge part of their policy , I am not against it, I just think we should not adopt everything :) -- Michael Scherer
Re: [Mageia-dev] Python Packaging Policy
2011/1/18 Michael Scherer m...@zarb.org: We can merge part of their policy , I am not against it, I just think we should not adopt everything :) Fine So I'll try to
