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

Andrzej Giniewicz gginiu at gmail.com
Mon Mar 18 08:13:42 EDT 2013


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
work.

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.

Cheers,
Andrzej.

On 18.03.2013 11:47, Zack Buhman wrote:
> scikits-learn[1] and python2-scikit-learn are duplicate.
> 
> I notified the author of scikits-learn that is package nameing is
> incorrect, prior to discovering a package by the correct name already
> exists, and he seems to be completely unwilling to correct the situation
> himself.
> 
> How to handle this, I don't know (as far as who the maintainer should
> be), but either scikits-learn should merge into python2-scikit-learn, or
> scikits-learn should be removed completely.
> 
> [1] https://aur.archlinux.org/packages/scikits-learn/
> [2] https://aur.archlinux.org/packages/python2-scikit-learn/
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/aur-general/attachments/20130318/89c13a0e/attachment.asc>


More information about the aur-general mailing list