Axel Thimm
2004-05-13 19:32:17 UTC
Well, boost-python would never be python-boost, since boost is the main
system and the python portion is an "add-on" for that specific piece.
Same goes for the other -python packages. But, the other packages are
now having a general tendency to be prefixed with 'python-'. I think
this has been discussed on other lists previously. But, anyhow, the
user really shouldn't be too concerned about the exact nomenclature of
packaging. Since, once they get it installed, what it's named doesn't
matter.
It matters for packagers, especially for cross-repo packaging, sincesystem and the python portion is an "add-on" for that specific piece.
Same goes for the other -python packages. But, the other packages are
now having a general tendency to be prefixed with 'python-'. I think
this has been discussed on other lists previously. But, anyhow, the
user really shouldn't be too concerned about the exact nomenclature of
packaging. Since, once they get it installed, what it's named doesn't
matter.
you need to be able to put proper Requires/BuildRequires in your
specfile. If half the world does SuperPyFoo (upstream name) and the
other half canonicalizes this to python-superfoo, or because it uses
/foo as a site-subfolder only python-foo, you will have confusion all
along (just like in the case of PIL, where users overlook
python-imaging).
The issue at hand is whether the user knows what their getting and
therefore the name should be something similar to the upstream package.
Nonetheless, lowercase and a python prefix in most cases would be a
good idea. But, remember that this method will not be a blanket policy
used in all situations.
Well, just look at the perl cousin wrt to lower/upper case. Also thetherefore the name should be something similar to the upstream package.
Nonetheless, lowercase and a python prefix in most cases would be a
good idea. But, remember that this method will not be a blanket policy
used in all situations.
"perl-" perfix argument cannot be transfered to python, just because
python is a better perl ;)
http://lists.atrpms.net/pipermail/repo-coord/2004-May/000307.html
http://lists.atrpms.net/pipermail/repo-coord/2004-May/000309.html
My recommendation (though not a strong one) is to leave the package as
named upstream. Or at least add virtual "Provides:" for the upstream
names, so that other packages with (Build)Requires: SuperPyFoo(-devel)
will not break.
BTW what is the situation with canonical naming in the python
community (aside from packaging)? perl does have a very strict scheme,
while the python community seems to have less a policy on that. I
think that the discussion about (re)naming in python should not be
carried outside the python community, e.g. if the names are "broken",
they should be "fixed upstream".
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20040513/e7259e76/attachment.bin
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20040513/e7259e76/attachment.bin