[opensuse-packaging] Subj: Packaging R extensions
Hello, I've recently had the need of some R extensions, so I packaged a few, but I couldn't find any SUSE guideline. Most of the ones I found are in devel:languages:R:CRAN-packages and they seem to be Fedora-related, but they hardly work. Is devel:languages:R:released the correct staging project for the ones that build? Any suggestion will be appreciated! Regards -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Sun, 19 Jun 2016 17:47:07 +0200
schrieb "Luigi Baldoni"
Hello, I've recently had the need of some R extensions, so I packaged a few, but I couldn't find any SUSE guideline.
Most of the ones I found are in devel:languages:R:CRAN-packages and they seem to be Fedora-related, but they hardly work. Is devel:languages:R:released the correct staging project for the ones that build?
I would think so. (owner of d:l:R:* speaking) What do you miss? Detlef
Any suggestion will be appreciated!
Regards
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Detlef Steuer-2 wrote
Am Sun, 19 Jun 2016 17:47:07 +0200 schrieb "Luigi Baldoni" <
aloisio@
>:
Hello, I've recently had the need of some R extensions, so I packaged a few, but I couldn't find any SUSE guideline.
Most of the ones I found are in devel:languages:R:CRAN-packages and they seem to be Fedora-related, but they hardly work. Is devel:languages:R:released the correct staging project for the ones that build?
I would think so. (owner of d:l:R:* speaking) What do you miss?
Well, I submitted the ones I was missing:) I'm confused about the following: what is the official path for noarch extensions? If I use %{_datadir}/R/library nothing detects its contents unless set via R_LIBS. Should this variable be set somewhere in the R global environment? Why so many packages have DESCRIPTION as %doc when it's apparently essential for it to be in %{rlibdir}/%{packname} ? In regard to versioning, since "-" is an illegal character, should "_" be used in its place? Or is "." better? -- View this message in context: http://opensuse.14.x6.nabble.com/Subj-Packaging-R-extensions-tp5066428p50664... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Sun, Jun 19, 2016 at 2:41 PM, Luigi Baldoni
Detlef Steuer-2 wrote
Am Sun, 19 Jun 2016 17:47:07 +0200 schrieb "Luigi Baldoni" <
aloisio@
>:
Hello, I've recently had the need of some R extensions, so I packaged a few, but I couldn't find any SUSE guideline.
Most of the ones I found are in devel:languages:R:CRAN-packages and they seem to be Fedora-related, but they hardly work. Is devel:languages:R:released the correct staging project for the ones that build?
I would think so. (owner of d:l:R:* speaking) What do you miss?
Well, I submitted the ones I was missing:)
I'm confused about the following:
what is the official path for noarch extensions? If I use %{_datadir}/R/library nothing detects its contents unless set via R_LIBS. Should this variable be set somewhere in the R global environment?
There is only a single path for all R libraries, %{_rlibdir}/R/library
Why so many packages have DESCRIPTION as %doc when it's apparently essential for it to be in %{rlibdir}/%{packname} ?
Because the DESCRIPTION file is a %doc and we want to categorize it appropriately. Also R libraries are "self contained" which is the reason the docs reside in %{rlibdir}/%{packname} and not in %{_defaultdocdir}/%{name}.
In regard to versioning, since "-" is an illegal character, should "_" be used in its place? Or is "." better?
Nearly all the CRAN packages were created with R2spec, https://fedoraproject.org/wiki/Packaging:R?rd=Packaging/R, which substitutes "-" with "." per Fedora's versioning standard.
-- View this message in context: http://opensuse.14.x6.nabble.com/Subj-Packaging-R-extensions-tp5066428p50664... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Darin Perusich-3 wrote
what is the official path for noarch extensions? If I use %{_datadir}/R/library nothing detects its contents unless set via R_LIBS. Should this variable be set somewhere in the R global environment?
There is only a single path for all R libraries, %{_rlibdir}/R/library
Is that %{_rlibdir} macro defined anywhere outside of spec files?
From what I could see each of them defines %{rlibdir} to point at %{_libdir}/R/library or %{_datadir}/R/library for noarch files (not to mention %{rdir}). The examples in the Fedora link below also show the same pattern.
Darin Perusich-3 wrote
Because the DESCRIPTION file is a %doc and we want to categorize it appropriately. Also R libraries are "self contained" which is the reason the docs reside in %{rlibdir}/%{packname} and not in %{_defaultdocdir}/%{name}.
Ok, will correct that at the earliest occasion. Darin Perusich-3 wrote
In regard to versioning, since "-" is an illegal character, should "_" be used in its place? Or is "." better?
Nearly all the CRAN packages were created with R2spec, https://fedoraproject.org/wiki/Packaging:R?rd=Packaging/R, which substitutes "-" with "." per Fedora's versioning standard.
It seemed to me that the underscore was more frequent in the existing packages, so I used that one. Can a rule for this be inferred from other SUSE naming/versioning standards? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/Subj-Packaging-R-extensions-tp5066428p50664... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Jun 20, 2016 at 11:52 AM, Luigi Baldoni
Darin Perusich-3 wrote
what is the official path for noarch extensions? If I use %{_datadir}/R/library nothing detects its contents unless set via R_LIBS. Should this variable be set somewhere in the R global environment?
There is only a single path for all R libraries, %{_rlibdir}/R/library
Is that %{_rlibdir} macro defined anywhere outside of spec files?
Not at this time, it's defined as a global in each SPEC. If i were going to change that I'd create an R-rpm-macros package to define those variables. See https://build.opensuse.org/package/show/server:monitoring/nagios-rpm-macros for an example.
From what I could see each of them defines %{rlibdir} to point at %{_libdir}/R/library or %{_datadir}/R/library for noarch files (not to mention %{rdir}). The examples in the Fedora link below also show the same pattern.
Darin Perusich-3 wrote
Because the DESCRIPTION file is a %doc and we want to categorize it appropriately. Also R libraries are "self contained" which is the reason the docs reside in %{rlibdir}/%{packname} and not in %{_defaultdocdir}/%{name}.
Ok, will correct that at the earliest occasion.
Darin Perusich-3 wrote
In regard to versioning, since "-" is an illegal character, should "_" be used in its place? Or is "." better?
Nearly all the CRAN packages were created with R2spec, https://fedoraproject.org/wiki/Packaging:R?rd=Packaging/R, which substitutes "-" with "." per Fedora's versioning standard.
It seemed to me that the underscore was more frequent in the existing packages, so I used that one. Can a rule for this be inferred from other SUSE naming/versioning standards?
The usage of the underscore is probably related to the spec's having been created with an older version of R2spec, and before it aligned itself with the Fedora Versioning Standard. There isn't a hard "requirement" for version in openSUSE/SUSE, other than no dashes, that I was able to find. Personally I prefer dot separators and the semantic versioning standards, but if you want to use underscores I'll still accept your SR's ;-) And thank you for helping to package the R libraries, it's really just Detlef and I and we really appreciate it!
-- View this message in context: http://opensuse.14.x6.nabble.com/Subj-Packaging-R-extensions-tp5066428p50664... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Darin Perusich-3 wrote
There is only a single path for all R libraries, %{_rlibdir}/R/library
Is that %{_rlibdir} macro defined anywhere outside of spec files?
Not at this time, it's defined as a global in each SPEC. If i were going to change that I'd create an R-rpm-macros package to define those variables. See https://build.opensuse.org/package/show/server:monitoring/nagios-rpm-macros for an example.
Sorry if I insist, but I'm still not sure if meanwhile the installation path macro should be differentiated for noarch and binary packages. Also I'm not sure how to determine the runtime requirements for each extension: should BuildRequires and Requires coincide? Or does rpm take care of that? Furthermore, are packages tied to the exact version of each extension they were built with? The only one I've tested seems to have problems of this sort. Regards -- View this message in context: http://opensuse.14.x6.nabble.com/Subj-Packaging-R-extensions-tp5066428p50664... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Jun 20, 2016 at 1:19 PM, Luigi Baldoni
Darin Perusich-3 wrote
There is only a single path for all R libraries, %{_rlibdir}/R/library
Is that %{_rlibdir} macro defined anywhere outside of spec files?
Not at this time, it's defined as a global in each SPEC. If i were going to change that I'd create an R-rpm-macros package to define those variables. See https://build.opensuse.org/package/show/server:monitoring/nagios-rpm-macros for an example.
Sorry if I insist, but I'm still not sure if meanwhile the installation path macro should be differentiated for noarch and binary packages.
Also I'm not sure how to determine the runtime requirements for each extension: should BuildRequires and Requires coincide? Or does rpm take care of that?
Yes the BuildRequires and Requires need to coincide otherwise the dependencies at build and install will not be met. R2spec does an OK job of setting the correct BuildRequires and Requires in the spec, but more often than now it misses some. This is why most of the packages in CRAN-packages are broken or fail to build and the spec's need to be manually updated. A lot of trial and error goes into building the packages successfully the first time, but afterwards it's simple to update them unless something significant changes.
Furthermore, are packages tied to the exact version of each extension they were built with? The only one I've tested seems to have problems of this sort.
I'm not sure what you mean. In OBS if package AAA has a dependency to package BBB, if package BBB is successfully updated then package AAA will be rebuilt once the updated package is published. So if R-base is updated then every package is dependent on it will be rebuilt.
Regards
-- View this message in context: http://opensuse.14.x6.nabble.com/Subj-Packaging-R-extensions-tp5066428p50664... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Mon, 20 Jun 2016 14:32:29 -0400
schrieb Darin Perusich
On Mon, Jun 20, 2016 at 1:19 PM, Luigi Baldoni
wrote: Darin Perusich-3 wrote
There is only a single path for all R libraries, %{_rlibdir}/R/library
Is that %{_rlibdir} macro defined anywhere outside of spec files?
Not at this time, it's defined as a global in each SPEC. If i were going to change that I'd create an R-rpm-macros package to define those variables. See https://build.opensuse.org/package/show/server:monitoring/nagios-rpm-macros for an example.
Sorry if I insist, but I'm still not sure if meanwhile the installation path macro should be differentiated for noarch and binary packages.
Also I'm not sure how to determine the runtime requirements for each extension: should BuildRequires and Requires coincide? Or does rpm take care of that?
Yes the BuildRequires and Requires need to coincide otherwise the dependencies at build and install will not be met.
Hmmm. Not sure if something changed there. When I submitted latest R-base to Factory I had to clean up the BuildRequires and Requires so that nothing, that was pulled implicitly, was pulled explicitly. I.e: BuildRequires: xz-devel, so Requires: xz was "forbidden". rpm does a lot of that automatically. It´s at least worth a try to comment out such explicit Requires. Detlef
R2spec does an OK job of setting the correct BuildRequires and Requires in the spec, but more often than now it misses some. This is why most of the packages in CRAN-packages are broken or fail to build and the spec's need to be manually updated. A lot of trial and error goes into building the packages successfully the first time, but afterwards it's simple to update them unless something significant changes.
Furthermore, are packages tied to the exact version of each extension they were built with? The only one I've tested seems to have problems of this sort.
I'm not sure what you mean. In OBS if package AAA has a dependency to package BBB, if package BBB is successfully updated then package AAA will be rebuilt once the updated package is published. So if R-base is updated then every package is dependent on it will be rebuilt.
Regards
-- View this message in context: http://opensuse.14.x6.nabble.com/Subj-Packaging-R-extensions-tp5066428p50664... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- Dr. Detlef Steuer Helmut-Schmidt-Universität Fakultät WiSo Holstenhofweg 85 22043 Hamburg Tel: 040/6541-2819 mail: steuer@hsu-hh.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Detlef Steuer
I.e: BuildRequires: xz-devel, so Requires: xz was "forbidden".
BuildRequires is for packages needed for building, Requires is for packages needed at runtime. I think it is unlikely that you need xz at runtime. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Jun 21, 2016 at 3:08 AM, Detlef Steuer
Am Mon, 20 Jun 2016 14:32:29 -0400 schrieb Darin Perusich
: On Mon, Jun 20, 2016 at 1:19 PM, Luigi Baldoni
wrote: Darin Perusich-3 wrote
There is only a single path for all R libraries, %{_rlibdir}/R/library
Is that %{_rlibdir} macro defined anywhere outside of spec files?
Not at this time, it's defined as a global in each SPEC. If i were going to change that I'd create an R-rpm-macros package to define those variables. See https://build.opensuse.org/package/show/server:monitoring/nagios-rpm-macros for an example.
Sorry if I insist, but I'm still not sure if meanwhile the installation path macro should be differentiated for noarch and binary packages.
Also I'm not sure how to determine the runtime requirements for each extension: should BuildRequires and Requires coincide? Or does rpm take care of that?
Yes the BuildRequires and Requires need to coincide otherwise the dependencies at build and install will not be met.
Hmmm. Not sure if something changed there. When I submitted latest R-base to Factory I had to clean up the BuildRequires and Requires so that nothing, that was pulled implicitly, was pulled explicitly.
I.e: BuildRequires: xz-devel, so Requires: xz was "forbidden".
In the context of this discussion, i.e R packages/add-on/libraries, you will nearly always need to define both the BuildRequires and Requires to fulfill the dependency chain because nearly all of these packages are noarch. RPM's automatic dependency scripts, find-{requires,provides}, evaluate shared libraries with ldd and objdump of which there are none for most R packages. Your example for R-base is different because the RPM will determine some of it's dependencies by evaluating the shared libraries. The same is true of R-curl, which has libcurl-devel as a BuildRequires but the install-time Requies is automatically generated by RPM.
rpm does a lot of that automatically. It´s at least worth a try to comment out such explicit Requires.
Removing the Requires is not a sufficient test, since the package will still install. You need to attempt to attach/load the library from within R by calling the library('package'), which will in turn attempt the load it's dependency chain.
Detlef
R2spec does an OK job of setting the correct BuildRequires and Requires in the spec, but more often than now it misses some. This is why most of the packages in CRAN-packages are broken or fail to build and the spec's need to be manually updated. A lot of trial and error goes into building the packages successfully the first time, but afterwards it's simple to update them unless something significant changes.
Furthermore, are packages tied to the exact version of each extension they were built with? The only one I've tested seems to have problems of this sort.
I'm not sure what you mean. In OBS if package AAA has a dependency to package BBB, if package BBB is successfully updated then package AAA will be rebuilt once the updated package is published. So if R-base is updated then every package is dependent on it will be rebuilt.
Regards
-- View this message in context: http://opensuse.14.x6.nabble.com/Subj-Packaging-R-extensions-tp5066428p50664... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
--
Dr. Detlef Steuer Helmut-Schmidt-Universität Fakultät WiSo Holstenhofweg 85 22043 Hamburg
Tel: 040/6541-2819 mail: steuer@hsu-hh.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Darin Perusich-3 wrote
Yes the BuildRequires and Requires need to coincide otherwise the dependencies at build and install will not be met. R2spec does an OK job of setting the correct BuildRequires and Requires in the spec, but more often than now it misses some.
Now I see I've made a mess with pretty much everything I submitted ;_; Does R2spec rely on the CRAN homepage to determine dependencies for each extension? Or perhaps it's the other way around? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/Subj-Packaging-R-extensions-tp5066428p50665... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Sun, Jun 19, 2016 at 11:47 AM, Luigi Baldoni
Hello, I've recently had the need of some R extensions, so I packaged a few, but I couldn't find any SUSE guideline.
There's nothing official at this time.
Most of the ones I found are in devel:languages:R:CRAN-packages and they seem to be Fedora-related, but they hardly work. Is devel:languages:R:released the correct staging project for the ones that build?
The d:l:p:R:CRAN-packages repo has nothing to do with Fedora, I'm not sure where you're getting that, but as the project description says they were automatically created from CRAN and may or may not work in their current state. The reason they "hardly work" is because I automated the downloading and package generation of the 5000+ packages to get them into OBS, and as a starting point for would-be packagers can more easily "fix" them and submit to d:l:p:R:released.
Any suggestion will be appreciated!
Regards -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Andreas Schwab
-
Darin Perusich
-
Detlef Steuer
-
Luigi Baldoni