[aur-general] duplicate package: scikits-learn python2-scikit-learn

Xyne xyne at archlinux.ca
Mon Mar 18 16:39:45 EDT 2013

On 2013-03-18 13:13 +0100
Andrzej Giniewicz wrote:

>Naming of scikits family of packages isn't so obvious. It was also
>raised in past, that naming them python-scikits is repeating, because
>there is no non-python scikits. scikits- and scikits2- was also
>suggested. Lately also names diverged, some packages were using
>scikits-* to denote the "scikits repository" later were renamed to
>"scikit-*" like in "one of scikits" or dropped it altogether. I'm
>hesistant to do renames in AUR because not all AUR helpers handle it
>well IIRC. And those packages work correctly, pulling correct
>dependencies. I prefer to do rename only once when moving to community,
>to cause troubles to users only once, not twice. Especially that it's
>directly pacman that takes care for it then, and it does it better by
>definition :)
>Why it's not there yet? Because I'm testing two approaches of dealing
>with scikits-base package - either as install script or single-file
>package. I'm leaning towards the first one, but keeping the scikits-base
>in AUR for other packages that depend on it - just making it also
>install it by install script. That way I will not have to move "single
>file" package into community. I just want to make sure people will have
>smooth upgrade. Also had other priorities like finding out why python
>bindings for insight toolkit does not build for so long. That's not easy
>task because most of those are generated by gcc-xml. I still have to
>make two other currently unmaintained and outdated and broken libraries
>I don't know why the rush to rename it right now. Meanwhile, I will
>continue my plan of moving them in when they are ready without loosing
>my time on rename now, causing extra trouble to users of this package.
>Normally, I'd merge one with less votes into one with more votes
>(especially that one with less votes is doing compile in package
>function), but because it was raised to attention that I'm unwilling to
>correct the situation (which was already explained in comments earlier -
>nr. 5 from top) - someone might think I did this, because it was my
>package, so prefer to stand back, letting someone else decide :P
>So, if someone thinks I should do differently, you are free to merge my
>package into the other one. I don't care about having one package more
>or less, so don't worry about me :) And I plan to move into community
>anyway when scikits stuff is _ready_ - which I can do even if I don't
>maintain it in AUR.
>Anyway, if we are at this - we can as well decide about naming of
>scikits here and now, once and for all scikits. Because same thing apply
>to all scikits in AUR, not only this one or only mine.
>I think we should have scikits-* scikits2-* to keep them consistent. It
>will already tell us that package in question is for python or python2,
>and that it originates from http://scikits.appspot.com/ - other approach
>would be just forgetting common origin for packages and creating long
>names like python2-scikit-timeseries or something, based on name from
>PyPi - where it is obvious that scikits = scientific python toolkits, so
>it's saying python twice.
>A historical note: scikits-* prefix was chosen earlier, because: 1)
>there were no support for python 3 yet (and like 90% of scikits still
>don't support python 3, just look when scipy got python3 support and
>they are scipy extensions), 2) all scikit had it in front also in names,
>3) they weren't really separate python packages, but SciPy toolkits,
>like extensions to library. It allowed to keep the name short.

Blah blah top-posting blah blah.
*pushes Andrzej out of the way and merges the package into python-scikits-learn*


I think we should maintain the standard of using the language prefix to denote
modules. The argument that you give for using "scikits-" does make sense, but
it could be used for any library that provides multiple stand-alone language
bindings. I would rather see python-foo, haskell-foo, ruby-foo than foo-python,
foo-haskell, etc. It maintains consistency and there should be fewer languages
than projects. It also indicates very clearly what the package contains.
Anything starting with "python2-" is a library for Python 2. foo-python2 could
be a library, a set of Python helper scripts, or a Python 2 implementation of
something named foo (maybe more?).

When you move it to [community], rename it python*- and include scikits*- in
the provides array. That should be clear enough for everyone, imo.


More information about the aur-general mailing list