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

On Sun, Jun 19, 2016 at 11:47 AM, Luigi Baldoni wrote:

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

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

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

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

On Tue, Jun 21, 2016 at 3:08 AM, Detlef Steuer wrote:

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