[arch-dev-public] [RFC] Python 3.3.0 and PEP 394

Sébastien Luttringer seblu at seblu.net
Thu Sep 13 17:26:35 EDT 2012


On Thu, Sep 13, 2012 at 10:27 PM, Florian Pritz <bluewind at xinu.at> wrote:
> On 13.09.2012 22:03, Rashif Ray Rahman wrote:
>> On 14 September 2012 02:18, Sébastien Luttringer <seblu at seblu.net> wrote:
>>> We also have python libraries not prefixed by python- (e.g: pyalpm,
>>> pycups, pygtk, etc), I think we should also update with
>>> pkgbase=pygtk
>>> pkgname=(python-gtk python2-gtk)
>>
>> That breaks common knowledge and conventional project names. This
>> happened with pyqt:

I'm not sure it's very important (and possible) to use the project
name without alteration in our package name.
As you said, the most important is to be able to find it (by a search)
with a minimum common sense.

Developer which use pyqt, will search something like:
$ pacman -Sqs pyqt4
eric
eric4
and doesn't found it. Because they may use the real name of the python
library (import PyQt4).

>>
>> python2-qt
>> python-qt
>>
>> Those look absolutely nothing like 'PyQt', which is the project name.
$pkgbase would be pyqt (or even PyQt). IIRC, archweb already display
split package by $pkgbase in "Recent Updates".

https://www.archlinux.org/packages/community/x86_64/linux-tools/
https://www.archlinux.org/packages/extra/x86_64/calligra/

Unfortunatly, packages doesn't have pkgbase information stored, so
pacman is not able to find by $pkgbase.
But we can use provides and groups to have a search working.

By example, use group information, named by project name, which allow
users which want use PyQt to search
pacman -Ss pyqt and found python-qt and python2-qt.
And users who (gracefully) writes "pacman -S pyqt" will be asked to
choose which package to install.

>> We worked around this for a while using 'PyQt:' in the description so
>> that it'd come up in searches for 'pyqt'. You could also provide for
>> it in both, but that would still be a workaround.
>
> python2-pyqt
> python2-pygtk
>
> The little bit of redundancy (python-py) isn't too bad IMHO and it's a
> clear naming scheme without special cases.

It's a compromise but squeezing the redundancy would be plus.
Even change the package name, change it to something much more coherent.

All of this works until there is no 2 different packages nammed PyQt4
and PythonQT. It's unlikely?

Cheers,

-- 
Sébastien "Seblu" Luttringer
www.seblu.net


More information about the arch-dev-public mailing list