Re: New source and binary Debian packages for ROOT.
Hi all,
[Sorry about the late response - I've been rather busy]
On Wed, 2006-01-25 at 12:37 -0500, Kevin B. McCarty wrote:
> On 1/25/06, Chris Roat <chris.roat@gmail.com> wrote:
>
> > I am sure now that I pulled down the unstable version (-3), as that is
> > what Christian announced. But I do think the audience is stable - it
> > is production, and -2 was in stable. I thought the drop into unstable
> > was just to signify that we were churning through and testing the
> > install fixes.
Erhm, the difference between 5.09.01-2 and 5.09.01-3 was I fixed some
build-dependencies. That's it. In terms of run-time, user experience,
the two are the same.
The differences between 5.09.01 (upstream) to 5.08 (patch level b or c)
are minor. Don't worry about it. 5.09.01 is as close to production as
possibly can be :-)
Actually, I'm up to revision 4 on my machine, but I haven't released it
yet. There was a problem on powerpc that I'd like to fix first.
The problem is, that some packages cannot be build on all platforms, as
the dependencies are not fulfilled on those platforms. For example,
the `root-plugin-maxdb' package can only be built on i386, ia64, and
amd64. Fine, so I make build dependencies like
libsqlod75-dev [i386 ia64 amd64]
and of course, I shouldn't try to build the package either, so I do
Package: root-plugin-maxdb
Architecture: i386 ia64 amd64
But, unfortunately that breaks on powerpc (thanks to Frederic for the
effort) with
dpkg-gencontrol: error: current build architecture powerpc does
not appear in package's list (i386 ia64)
Anyone now what's going on? Thanks.
Also, it seems that I need to change the plug-in package
`root-plugin-minuit' to extension packages `libroot-minuit' and
`liroot-minuit-dev' :-(
> No, the ROOT Debian packages in "unstable" are meant to be installed
> on a system running Sid, while those in "stable" are meant to be
> installed on a system running Sarge. (Not quite sure which ones Etch
> users are supposed to use.) This explains the confusion. The version
> numbers only differ because (I guess) no one has built -3 for Sarge
> yet.
I think `etch' users should grab the `sid' ones.
> > Again, though, this is off-my-original-post-topic of why put libraries
> > in hidden places?
>
> My understanding, from what Christian has told me, is that libMinuit
> is a "plugin" -- it is meant to be loaded automatically from within
> the depths of the ROOT libraries, so it doesn't need to be linked
> against. If you want to call a fitter explicitly within your own
> code, you should use the TVirtualFitter base class and the
> /etc/root/system.rootrc file, which have mechanisms for doing so.
Exactly. In that way, the _user_ is free to chose exactly which fitter
to use. The choice lies with the end-user, not the mediocre
developer :-)
Another good example of a virtual interface, is the TSQLServer
interface. A user, developer, what not, may do
TSQLServer* server = TSQLServer::Connect(<url string>);
The <url string> has a tad of a specific structure and meaning. Here's
some examples of (semi) valid urls:
mysql://127.0.0.1/test
pqsql://127.0.0.1/test
sapdb://127.0.0.1/test
oracle://127.0.0.1/test
Of course TSQLServer doesn't know about all these different kind of
databases. What `TSQLServer::Connect' does, is that it looks at the
`protocol' part of the URL, looks up in `/etc/root/system.rootrc' to if
there's a handler, and if there is, what library to load to use that
handler, and finally it makes and instance of the handler. So the above
URLs results in the following constructions:
mysql://127.0.0.1/test -> new TMySQLServer
pqsql://127.0.0.1/test -> new TPqSQLServer
sapdb://127.0.0.1/test -> new TSapDBServer
oracle://127.0.0.1/test -> new TOracleServer
The abstract interface TFile also handles various protocols like this:
TFile::Open("file://...") -> Normal TFile
TFile::Open("rootd://...") -> TNetFile
TFile::Open("castor://...") -> TCastorFile
TFile::Open("dcache://...") -> TDcacheFile
TFile::Open("grid://...") -> TXNetFile (or something like that)
> That said, it appears that the RooFit code *incorrectly* uses
> libMinuit-specific code without going through the plugin manager. IMO
> this is a bug,
I feel the same way :-)
> and it can probably be fixed using the suggested change
> I gave in my previous email (sent from my princeton.edu account), in
> addition to causing libRooFit *not* to be dynamically linked against
> libMinuit at build time.
Which would be a great help. Ah well, ROOT should really split the
libraries from the plug-ins, but sometimes backward compatibility weighs
more heavy than good design :-(
Yours,
--
___ | Christian Holm Christensen
|_| | -------------------------------------------------------------
| | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91
_| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91
_| Denmark Office: (+45) 353 25 404
____| Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
| |
Reply to: