[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[edd@debian.org: ]

Dirk requested that somebody forwarded this to the list, so here goes. :-)

/* Steinar */
Homepage: http://www.sesse.net/
--- Begin Message ---
<edd@debian.org>, Bdale Garbee <bdale@gag.com>, Manoj Srivastava
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
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
      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 
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

		   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
   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
     (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 ---

Reply to: