--- Begin Message ---
<edd@debian.org>, Bdale Garbee <bdale@gag.com>, Manoj Srivastava
<srivasta@debian.org>
Bcc:
Subject: Re: Bug#266837: rpvm_0.6.2-1_hppa: FTBFS: relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
Reply-To:
In-Reply-To: <[🔎] 16715.25756.63028.45665@davenant.relativity.greenend.org.uk>
This is still as confusing to me as it was when this bug report was opened.
Either I am missing a basic principle here, despite having maintained
packages for Debian for over nine years. Or, and I hope that is the case
here, you may lack some insights into this particular case at hand.
So let me make another attempt at situating this.
1. GNU R is "a language and an environment" as per its own documentation.
2. As such, it provides facilities to build "packages" for R in a way
that is
- platform-indepent: the same mechanism works on all Linux flavours,
Unix flavours, OS X and even Windows (up to minor details imposed by
the problems with path and filenames);
- very mature and reliable;
- entirely scripted, under a Unix-ish OS a package foo compiles and
installs via 'R CMD INSTALL foo_1.2-3.tar.gz' which then calls
configure (if needed), make etc pp. A second and equivalent form is
'R CMD INSTALL .' from inside the unpackage directory;
- all platform-dependent compile-time flags are stored in a conffile
edd@homebud:~> grep -ci pic /etc/R/Makeconf
6
edd@homebud:~>
where e.g. the '-fPIC' requirement is imposed by the 'host' R
system, and not the 'client' R packages that is to be installed.
These settings come from the configure run of r-base, the main
R package.
- rigourously tested on over 350 packages against three releases
* 'release', the current official R (right now 1.9.1)
* 'patched', the changes that may end up in the next minor release
* 'devel', the trunc for the next major release
as one can see at
http://cran.r-project.org/src/contrib/checkSummary.html
3. Because it is so scripted, I as principal maintainer for R and the
majority of r-(cran|bioc|omegahat|noncran|other)-* packages, have
developed a standardized debian/rules file of a handful of lines making
use of cdbs facilities (and should one day contribute that back into cdbs
as a stanza). There is also a proposed 'Debian R Policy' that was posted
to the Debian (and R) devel lists on or around Dec 30 of last year.
The debian/rules, taken from an arbitrary package:
-------------------------------------------------------------------------
#!/usr/bin/make -f
# -*- makefile -*-
# debian/rules file for the Debian/GNU Linux r-cran-rgl package
# Copyright 2004 by Dirk Eddelbuettel <edd@debian.org>
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/langcore.mk
## We need the CRAN (upstream) name
cranName := $(shell grep Package: DESCRIPTION | cut -f2 -d" ")
## and we need to build a Debian Policy-conformant lower-case package name
cranNameLC := $(shell echo $(cranName) | tr "[A-Z]" "[a-z]" | tr "." "-" )
## which we can use to build the package directory
package := r-cran-$(cranNameLC)
## which we use for the to-be-installed-in directory
debRlib := $(CURDIR)/debian/$(package)/usr/lib/R/site-library
common-install-indep:: R_any_arch
common-install-arch:: R_any_arch
R_any_arch:
dh_installdirs usr/lib/R/site-library
R CMD INSTALL -l $(debRlib) --clean .
rm -vf $(debRlib)/R.css $(debRlib)/$(cranNameLC)/COPYING
-------------------------------------------------------------------------
As you can see, we do /nothing/ but calling R CMD INSTALL, with the
one indirection to have it install below $(CURDIR). Just like rpvm, rgl
is very much dependent on specific libraries, but we do not to make
any special efforts here to configure this. Build-Depends are sufficient.
4. To give you some perspective, we have over 60 packages built that way
in Debian:
edd@homebud:~> apt-cache search "^r-(.*cran|omegahat|bioc|other)-" | wc -l
63
and, for that matter, my Quantian project for scientific computing (see
http://dirk.eddelbuettel.com/quantian) has over 450:
edd@chibud:~> ls -1 src/progs/perl/cran2deb/builds/r-*.deb | wc -l
528
(some builds are two versions of the same source)
This included packages from the BioConductor (www.bioconductor.org)
project for genomics / bioinformatics which is built entirely on top
of R.
5. Now, what does this have to do with rpvm and pvm? If and when a package
doesn't build -- just like rpvm on non-i386/arm -- because the
/required/ libraries for its build are not provided by their respective
maintainer(s) and upstream author(s), then I consider it to be a problem
in that required library. E.g., it is for exactly that reason that I
worked to make the (parallel RNG) library sprng available in Debian ---
with new Makefiles, as the upstream built was static-lib only without
-fPIC etc pp.
6. Your suggestion of making 'any changes to rpvm to make use of the new
library' is wrong. R does what in can to build a variety of several
hundred packages. If something does not build because basic assumptions are
not met -- despite the fact that Debian Policy /clearly/ requires them --
then asking R to code around it is plain wrong. After all, we do have
the Debian Policy to be able to rely on basic assumptions.
7. Which is why I won't code around the shortcoming in the pvm library.
Not every package will always be available on all platforms. But until
the pvm libraries can be built in a Debian Policy-compliant way, I don't
see how we're going to have rpvm on more than the current two or three
arches. I don't have time to patch packages outside of my 70-plus packages,
Quantian, real life, and what have you.
8. As has been pointed out, this is not a RC bug as the package never existed
anywhere outside of the -fPIC tolerant arches.
9. I have made my case as to why I believe that this is not a bug in rpvm.
Rpvm does exactly what 60-plus other packages do. It fails because pvm
is not Policy-compliant. It does not fail because of shortcomings in
its code or packaging.
10. I made my case, someone else asked for rule by committee. So be it.
You may decide that it is a bug in rpvm despite my best efforts to prove
the contrary. In any event, I am rather unlikely to be dedicating much
time to fixing pvm, so unless something happens there, the status quo of
this issue is unlikely to change.
Someone please forward this to debian-ctte where I cannot post for lack of
a subscription. I have CC'ed just about anybody who has contributed to this
thread in the past.
Thanks for listening.
Regards, Dirk
PS Ian, great to hear from you. A few years ago, you offered to
reverse-adopt your own auto-pgp package I RFA'ed over five years ago. Are
you still interested?
--
Those are my principles, and if you don't like them... well, I have others.
-- Groucho Marx
--- End Message ---