On Mon, 23 May 2005, Dirk Eddelbuettel wrote:
> On 23 May 2005 at 15:24, Don Armstrong wrote:
> > On Mon, 23 May 2005, Dirk Eddelbuettel wrote:
> > > The (upstream) R Core team is very careful not to "promise" entry
> > > points to R that it won't be able to support. So I doubt that you
> > > will get them to export other header files.
> >
> > If that's the case, that's a slight problem, because rpy uses an
> > unsuported entry point. [Yet another reason why distributing
> > separate copies of headers is generally a bad idea.]
>
> The R API has been in changing, yet rpy is /much/ older than the new
> interfaces. Part of this is a historical happenstance, as Greg said
> in his email this is about to get cleaned up. So no need to be
> obsessed here.
That's good that it's about to get cleaned up. For the record, I am in
total agreement with the way it is being fixed currently,[1] as that
is the only sane thing to do at this juncture.
What I'm talking about (and why I'm continuing this discussion) is the
optimal resolution of this issue, post sarge release, by fixing:
1) r-base-core to provide the correct headers/fix whatever headers
are supplied
2) rpy to use the headers that are supplied by the system, and only
fall back to the package copy if there are no headers in the
system. [In the Debian build, falling back should probably cause
an FTBFS.]
These are both wishlist items, which is why the bug I cloned off was
severity wishlist.
> > Just tag it wontfix and/or forward it upstream.
>
> No, after mulling this over all day, I have decided to close it.
That basically precludes any further discussion, and will likely
result in this issue being raised again wihtout the benefit of the
current discussion.[2] I strongly suggest that you reopen this bug and
tag it wontfix, or allow me to reopen it for you. (This is precisely
why we have the wontfix tag.)
> I do not think that changing the set of distributed header files is
> a good idea.
Can you explain why?
Surely if rpy needs to link with the headers to provide its
functionality the R package should also provide them in its API, even
if they're marked as being volatile or not actively supported?
This may be a difficult bug to fix, and it may not be something that
upstream wants to tackle initially, but it sure seems to me like the
ideal situation.
(The only other alternative I can see is that rpy is using an
interface that it shouldn't be using and should be fixed to not use
that interface... in which case, reassigning the wishlist bug to rpy
asking for it to be fixed not to use the interface would be the right
way to proceed.)
> r-base-dev is NOT a standard Debian packages, it is more of a
> virtual package to ensure people also install a Fortran compiler,
> readline/curses headers etc pp.
Well, it is a real live standard Debian package... it just doesn't
contain anything useful.
In a perfect world, it would be ideal to separate out the headers
totally from the package so casual R users didn't actually have to
have the headers installed (like the machines I have R on that users
don't get to install stuff on) especially since we've already incured
the overhead of the -dev package.
But that's an issue even less acute than the "which headers to
distribute" question.
Don Armstrong
1: In fact, the only reason why I even commented on this bug was
because I was asked to see if there was a way to fix this with a
smaller delta... there would have been if Startup.h was actually
distributed by r-base-core.
2: If you don't feel it's worth implementing, but it is a reasonable
request, that's what the wontfix tag is for. I'd hope in light of the
RC bug that hit rpy you'd consider this a reasonable request, and
would hope that it was worth implementing eventually.
--
"Because," Fee-5 explained patiently, "I was born in the fifth row.
Any fool would understand that, but against stupidity the very Gods
themselves contend in vain."
-- Alfred Bester _The Computer Connection_ p19
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
