[aur-general] duplicate package: scikits-learn python2-scikit-learn
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/
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/
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 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.
Blah blah top-posting blah blah. *pushes Andrzej out of the way and merges the package into python-scikits-learn* /jk 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. Regards, Xyne
participants (3)
-
Andrzej Giniewicz
-
Xyne
-
Zack Buhman