From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-December/020780.html | 107 +++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-December/020780.html (limited to 'zarb-ml/mageia-dev/2012-December/020780.html') diff --git a/zarb-ml/mageia-dev/2012-December/020780.html b/zarb-ml/mageia-dev/2012-December/020780.html new file mode 100644 index 000000000..99accb494 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-December/020780.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Python packaging policy + + + + + + + + + +

[Mageia-dev] Python packaging policy

+ Pierre-Malo Deniélou + pierre-malo.denielou at rhul.ac.uk +
+ Thu Dec 13 21:35:29 CET 2012 +

+
+ +
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
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1