Platform-restricted packages (was Re: [Rd] RE: [Rcom-l] rcom 0.97 available for download)

From: Prof Brian Ripley <>
Date: Tue 27 Jul 2004 - 19:05:28 EST

This thread seems to have come to an end. To attempt to summarize:

It seems which are the exceptions and exactly what the restrictions are needs human judgement (and normally depends on the non-availability of other software, e.g. mim or Oracle). Given that, we have to rely on the package maintainers providing the information (possibly with a hint from the CRAN maintainers if the package does not run on i386 Debian Linux).

[BTW, fork gtkDevice RmSQL RSvgDevice are examples of Linux/Unix only and I think the complete such list is longer than the Windows-only one.]

The best I can come up with is an optional field (not SystemRequirements as that is documented for something else), say OSRequirement with suggested values `Windows' `MacOS X', `most useful under Windows' ....

BTW, SystemRequirements appears to be missing in almost all cases where it is needed, and

regress/DESCRIPTION:SystemRequirements: R spatialCovariance/DESCRIPTION:SystemRequirements: R

are not helpful. Only two instances (out of five) seem useful, and I think it should be used by at least

RArcinfo RODBC RMySQL ROracle RQuantLib RScaLAPACK RmSQL Rmpi RSvgDevice gtkDevice hdf5 mimR ncdf rgdal rgl rimage rpvm rsprng udunits

This does not bode well for suggesting a new field. I would find it more helpful if these were resolved than if the OS dependencies were ....

On Wed, 21 Jul 2004, Martin Maechler wrote:

> >>>>> "Dirk" == Dirk Eddelbuettel <>
> >>>>> on Wed, 21 Jul 2004 09:49:24 -0500 writes:
> Dirk> On Wed, Jul 21, 2004 at 04:40:46PM +0200, Uwe Ligges wrote:
> >> Dirk Eddelbuettel wrote:
> >>
> >> >On Wed, Jul 21, 2004 at 09:39:29AM -0400, Liaw, Andy wrote:
> >> >
> >> >>Would it make sense to have platform specific packages in a separate area
> >> >>on
> >> >>CRAN? I don't know of anything other than Windows that understand COM.
> >>
> >> The question is: What exactly is platform-specific?
> Dirk> Platform-specific means what it says -- works only on
> Dirk> a given platform (or maybe a few). Or are trying to
> Dirk> pull a Clinton here: "it depends was your meaning of
> Dirk> platform is" ? :)
> >> >Yup, and 'core' CRAN contains at least one Windows-only
> >> >package: rbugs [ as I found when working on a script to
> >> >automagically build Debian packages from CPAN packages,
> >> >the script is a modified version of Albrecht's script ]
> >>
> >> The author told me that rbugs is intended to work with WinBUGS under
> >> wine on a linux system (whereas I'm pretty sure R2WinBUGS is capable -

mimR is a better example, I think.

> Dirk> Think about it, what does 'run under wine' mean? Do
> Dirk> you get it: it ain't no native package when it needs
> Dirk> an emulator.
> Dirk> Saying it runs under Linux using wine is like claiming
> Dirk> your car just turned into a boat. While it will float
> Dirk> once driven into the river, I presume it won't float
> Dirk> for very long ...
> >> Where's the point not to have just this one source repository related to
> >> platform dependency?
> Dirk> Precisely. Let's have one source repo but _let us
> Dirk> label any and all binary restrictions_ more clearly so
> Dirk> that I for one can skip over stuff that may build for
> Dirk> you [ Windoze ] but won't for me [ Linux, preferable
> Dirk> on all all ten to twelve hardware platforms supported
> Dirk> by Debian for packages that get uploaded ].
> Dirk> Does that make sense? Would it improve over what we currently have?
> Yes (2x).
> I'd prefer to keep those packages in one place and rather mark
> them than to move them to specific directories.
> E.g., Dirk's proposal will also work when a package only works,
> in IBM AIX and in Windows.

Brian D. Ripley,        
Professor of Applied Statistics,
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________ mailing list
Received on Tue Jul 27 19:10:42 2004

This archive was generated by hypermail 2.1.8 : Wed 03 Nov 2004 - 22:45:03 EST