More updates for the policy
Hello, a last remark/discussion. Given that the XS-Python-Version field is no more required, I think it shouldn't be mentionned as part of the official policy but only as example on how to implement the policy with the help of python-central. I will update the wiki page as soon as the updated packages reach unstable: http://wiki.debian.org/DebianPython/NewPolicy 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: More updates for the policy
* Raphael Hertzog ([EMAIL PROTECTED]) [060619 19:31]: a last remark/discussion. Given that the XS-Python-Version field is no more required, I think it shouldn't be mentionned as part of the official policy but only as example on how to implement the policy with the help of python-central. I will update the wiki page as soon as the updated packages reach unstable: http://wiki.debian.org/DebianPython/NewPolicy Sorry, but I really disagree very much. We shouldn't have two vastly different ways to do it. Either, XS-Python-Version is the right thing. Than it should be in policy. Or there is another good mechanismn. Then it shouldn't be in policy. But - it should be uniform across source packages. The new dak headers were explicitly mentioned in Mexico, and there was more than one reason to add them. If we want to drop them again, we really should discuss them here, and speak about the reasons we had in Mexico to accept them. And, I don't think that they're no more required right now - just dh_python could live without them. And I really want further discussions before jumping to conclusions. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More updates for the policy
Hi Andy, On Mon, 19 Jun 2006, Andreas Barth wrote: We shouldn't have two vastly different ways to do it. Life would be best if we had already taken a decision... we know this but it is not going to happen until we have more experience with both python-central and python-support. Either, XS-Python-Version is the right thing. Than it should be in policy. Or there is another good mechanismn. Then it shouldn't be in policy. Policy should document usage. Right now we're starting to use python-central and python-support and we don't know which approach is best. So the policy shouldn't favor either approach but rather document what's common between both approaches. The common part is quite clear: - everything in one python-foo - the dependencies that have to be generated The new field is not part of the common part. For technical reasons, we have to find a way to differentiate clearly between new policy and old policy and for this the best approach suggested is the idea of Pierre Habouzit, a Standards-Version field dedicated to Python. It's the smallest common denominator that I have found on which both parties could agree. The new dak headers were explicitly mentioned in Mexico, and there was more than one reason to add them. What are those reasons? I only know two reasons for those headers: - python-central use them for its internal work - it may help track a transition and discover which packages need to be updated BTW, the syntax of the Python-Version field comes directly from python-central and it has not been discussed if the current syntax is the best needed to achieve the second point. I can easily find out packages which need to be updated for a python transition by looking for packages with a dependency python ( 2.X). If we want to drop them again, we really should discuss them here, and speak about the reasons we had in Mexico to accept them. I welcome discussion as always. And, I don't think that they're no more required right now - just dh_python could live without them. And I really want further discussions before jumping to conclusions. Right, and the dh_python change doesn't forbid maintainer to continue using XS-Python-Version as it will continue to work without problem. That's why I'll go forward with the change and we'll have more time for discussing what we want in the long term. 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: More updates for the policy
* Raphael Hertzog ([EMAIL PROTECTED]) [060619 21:08]: On Mon, 19 Jun 2006, Andreas Barth wrote: We shouldn't have two vastly different ways to do it. Life would be best if we had already taken a decision... we know this but it is not going to happen until we have more experience with both python-central and python-support. My impression was that we *did* a decision how to handle the meta-information, and just didn't decide about the implementation. The common part is quite clear: - everything in one python-foo - the dependencies that have to be generated The new field is not part of the common part. For technical reasons, we have to find a way to differentiate clearly between new policy and old policy and for this the best approach suggested is the idea of Pierre Habouzit, a Standards-Version field dedicated to Python. It's the smallest common denominator that I have found on which both parties could agree. A Standards-Version-Header is definitly a good idea, I agree on that. However, I'd really like to see more information in the control-part - like we see e.g. the maintainer or build-dependencies listed there (without the real technical need, all that could be extracted from debian/control as well). I only know two reasons for those headers: - python-central use them for its internal work - it may help track a transition and discover which packages need to be updated BTW, the syntax of the Python-Version field comes directly from python-central and it has not been discussed if the current syntax is the best needed to achieve the second point. Obviously, nobody hit by the second purpose (which includes me) has any issue with the current syntax. Otherwise, I would have said something. I can easily find out packages which need to be updated for a python transition by looking for packages with a dependency python ( 2.X). not necessarily, if we e.g. just add a new python suite - i.e. at the start of a transition. Also, sometimes one wants to check what problems will occur without doing the transition at the same time. You could equally well argue that we don't need build-dependencies listed - anybody who wants to build a package will need to download source anyways, and will find out. Neverthelesse, they have proven to be quite successfull. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More updates for the policy
On Mon, 19 Jun 2006, Floris Bruynooghe wrote: On Mon, Jun 19, 2006 at 09:07:00PM +0200, Raphael Hertzog wrote: BTW, the syntax of the Python-Version field comes directly from python-central and it has not been discussed if the current syntax is the best needed to achieve the second point. This is a valid point. But if it is found to be a concern/problem and there are good reasons to change it I'm sure that could be done. No because if you change the syntax, you will break packages using python-central... ie once python-central has been released within a stable release it will be almost impossible to change the syntax. Cheers, PS: Thanks for joining the discussion, we really need more opinions and fresh blood. :) -- 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: More updates for the policy
On Mon, 19 Jun 2006, Andreas Barth wrote: My impression was that we *did* a decision how to handle the meta-information, and just didn't decide about the implementation. You can review the video of the BoF but I don't have time for that. common denominator that I have found on which both parties could agree. A Standards-Version-Header is definitly a good idea, I agree on that. Good. However, I'd really like to see more information in the control-part - like we see e.g. the maintainer or build-dependencies listed there (without the real technical need, all that could be extracted from debian/control as well). Then please ask people to use XS-Python-Version and XS-Python-Standards-Versions together. And over time, if it has technical merits, it will win. Today, you can perfectly use the new python-support with the X[SB]s-Python-Version fields but you can also use it without. I only know two reasons for those headers: - python-central use them for its internal work - it may help track a transition and discover which packages need to be updated BTW, the syntax of the Python-Version field comes directly from python-central and it has not been discussed if the current syntax is the best needed to achieve the second point. Obviously, nobody hit by the second purpose (which includes me) has any issue with the current syntax. Otherwise, I would have said something. You expressed concerns on the syntax on IRC. Because the , means or in somes cases like 2.1, 2.2 and it means and in some other cases = 2.2, 2.5. Also if the field describes the list of python versions that the package can work with, then the current value has no meaning... current exists only to let the maintainer build only for the current python version. Which is orthogonal to the meaning of the field. I can easily find out packages which need to be updated for a python transition by looking for packages with a dependency python ( 2.X). not necessarily, if we e.g. just add a new python suite - i.e. at the start of a transition. Also, sometimes one wants to check what problems will occur without doing the transition at the same time. Well, you're confused if I have python ( 2.5) it means the package won't work with python2.5 right now and also that the extension (for arch: any packages) has not yet been compiled for python2.5. 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]
