naund [1] filed a request to merge r-cran-curl [2] into r-curl [3]:
Both providing the same content and generating dependency problems.
[1] https://aur.archlinux.org/account/naund/ [2] https://aur.archlinux.org/pkgbase/r-cran-curl/ [3] https://aur.archlinux.org/pkgbase/r-curl/
Hi naund, hi all,
fordprefect here. I see your argument and appreciate your effort to clean up, but after a short check in the AUR, the prevailing naming scheme seems to be r-cran-$modulename not r-$modulename. I would follow the argument to rename all packages to cran-$modulename, since cran (Comprehensive R Archive Network) contains the R reference already, but omitting cran in the package name is not a good choice in my opinion. I regard r-curl as a duplicate of r-cran-curl and suggest merging the other way around. If you like, you can take the ownership of the package. That should not hinder a sensible solution here.
Best Georg
Am 09.07.2017 um 00:11 schrieb notify@aur.archlinux.org:
naund [1] filed a request to merge r-cran-curl [2] into r-curl [3]:
Both providing the same content and generating dependency problems.
[1] https://aur.archlinux.org/account/naund/ [2] https://aur.archlinux.org/pkgbase/r-cran-curl/ [3] https://aur.archlinux.org/pkgbase/r-curl/
Hallo,
Am Sonntag, 9. Juli 2017, 11:01:46 CEST schrieb G. Schlisio:
I see your argument and appreciate your effort to clean up, but after a short check in the AUR, the prevailing naming scheme seems to be r-cran-$modulename not r-$modulename.
I have launched the request, because I was not able to install ggplot2, dplyr and tidyr using aur, which are quite standard for r. Main probles are several dependency problems because of duplicated packages with different names in aur. The first step should be to clean up t he mess introduced by duplicated packages. In order to avoid further duplicates, a common naming scheme should be choosen as second step.
If you like, you can take the ownership of the package. That should not hinder a sensible solution here.
For me the main issue is the coordination of the package reorganisation, which goes beyond the ownership of simple packages. I could maintain some easy packages, but because I'm using R not very frequentoy on my privte laptop, I will miss some upstream updates for sure.
Regards Nils
Hi Nils,
I agree that in the first place the AUR should just work. Therefore we need an appropriate naming scheme for R packages. The Archwiki page on R [0] does not refer to any packages but advocates installing via the internal module management of R. This might be useful for private scipts and stuff, but since other packages cannot depend on that, we still need R packages in the AUR. The Arch packaging standards [1] do not state anything applicable and there are also no R packaging guidelines at the moment. Looking at the Perl packaging standards [2] I notice, that even though perl packages are (presumably) mostly from CPAN, perl packages are named perl-$modulename. Thus I think we should set up a wiki page "R packaging guidelines" and fix the R-specific rules there. Once we agreed on those, we can begin adapting packages to the new rules. Following the example of perl this could well imply a naming scheme like r-$modulename.
That said, I do not have the time to do all this at the moment. I dont use R and its modules at all atm, I just update them when an update comes in. I keep track of updates with a Firefox extension whose name I dont remember now. If you are interested, I can find it out for you.
Best Georg
[0] https://wiki.archlinux.org/index.php/R#Installing_R_packages [1] https://wiki.archlinux.org/index.php/Arch_packaging_standards#Package_naming [2] https://wiki.archlinux.org/index.php/Perl_package_guidelines
On Jul 12, 2017 4:03 AM, "Georg" g.schlisio@dukun.de wrote:
Hi Nils,
I agree that in the first place the AUR should just work. Therefore we need an appropriate naming scheme for R packages. The Archwiki page on R [0] does not refer to any packages but advocates installing via the internal module management of R. This might be useful for private scipts and stuff, but since other packages cannot depend on that, we still need R packages in the AUR.
Does anything besides other R packages actually depend on any R packages from the AUR? Assuming the andswer is no, is there any advantage to having R packages in the AUR at all?
Best, Ista
The Arch packaging standards [1] do not state anything applicable and there are also no R packaging guidelines at the moment. Looking at the Perl packaging standards [2] I notice, that even though perl packages are (presumably) mostly from CPAN, perl packages are named perl-$modulename. Thus I think we should set up a wiki page "R packaging guidelines" and fix the R-specific rules there. Once we agreed on those, we can begin adapting packages to the new rules. Following the example of perl this could well imply a naming scheme like r-$modulename.
That said, I do not have the time to do all this at the moment. I dont use R and its modules at all atm, I just update them when an update comes in. I keep track of updates with a Firefox extension whose name I dont remember now. If you are interested, I can find it out for you.
Best Georg
[0] https://wiki.archlinux.org/index.php/R#Installing_R_packages [1] https://wiki.archlinux.org/index.php/Arch_packaging_standard s#Package_naming [2] https://wiki.archlinux.org/index.php/Perl_package_guidelines
Request #8462 has been accepted by Alad [1].
aur-requests@lists.archlinux.org