[pkg-bioc] Questions before breaking everything...

[Steffen Moeller]

Hi David,

On Sunday 24 June 2007 19:11:46 David Vernazobres wrote:
> On Thu, Jun 21, 2007 at 08:15:57AM -0500, Dirk Eddelbuettel wrote :
> > On 21 June 2007 at 12:43, David Vernazobres wrote:

> > Steffen's concern about setup-speed are noted, but I think there is an
> > option for pbuilder to _not_ close it after one build. That's excactly
> > what we need, it's just a matter of setting it up.
>
> But in this case, we will build some package with a non clean fresh build
> system. Which I will not recommend, for clean dependency resolution.
If pbuilder does not remove the additionally installed files post compilation, 
and if it was started from that state for the next compilation, then pbuilder 
would be superfluous, indeed. I presume that what we are aiming at is 
something like a buildd behaviour that installes and deinstalls packages but 
leaves the remainder intact. However, the untaring of a complete system for 
every package, I think we can agree here, is not elegant with respect to the 
utilisation of our resources. It may appear to be required for complete 
security, but it is not elegant. 

> I will not commit yet, and scratch my head a bit harder to support
> pbuilder and sudo, then.
Commit it, please. The sudo-bits should be fairly trivial to add back in as a 
separate module or so. They were trivial to add in the first implementation 
at least :o)

> For the Love'n'Hate conflict, I am really thinking in forking cran2deb to a
> new build system, with a try to a more clean program, building cran, bioc,
> omegahat in one row. Our system is working, but not nicely enought in my
> point of view. suggestions ? (and this is not a *TROLL*!thx)
Much of the ugliness comes from having to treat the three worlds separately. 
Hence, I can wholeheartedly agree to a concept that integrates these worlds. 
However, we should not expect everyone to mirror everything in order to 
contribute to our effort. The shared repository on alioth in the respect 
helps here to resolve the dependencies across repositories. I am hence not 
overly much worried.

I admire you for your time that you invest for making something functional 
also nice and clean and adorable and ... understandable. This attitude is 
very much needed in order to reach higher grounds above what has been reached 
already and I want to encourage you to proceed with your plans.

Btw, the upload of the bio-2.0 amd64 packages via my not so quick DSL link to 
the shared repository has almost completed. I'll add the remainder tonight, I 
think. I was surprised to find all the environments of R, the kind of DB 
substitute to store tons of information, to be platform dependent. All the 
chip descriptions for instance are platform dependent. This is mightily 
annoying for us should we manage to get three different archs for Debian 
(ppc, i386, amd64, ... I stalled my initial plans to come up with Sparc64).

Viele herzliche Gruesse

Steffen

-- 

Dr. Steffen Möller
University of Lübeck
Institute for Neuro- and Bioinformatics
Ratzeburger Allee 160
23538 Lübeck
Germany
T: +49 451 500 5504
F: +49 451 500 5502
moeller at inb.uni-luebeck.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-bioc-devel/attachments/20070625/e3dfd42b/attachment.pgp