[pkg-bioc] how to proceed?

[Dirk Eddelbuettel]

On 22 February 2005 at 10:29, Egon Willighagen wrote:
| On Monday 21 February 2005 23:25, Dirk Eddelbuettel wrote:
| > | 3. also added a section to can't build for package problems on CRAN
| > |   e.g gmp is mentioned in Descriptions/ but the tar.gz is missing on CRAN
| > |   others that seem to suffer from similar issues are: boa, mnp
| >
| > Way have been a temporary mirror glitch. I follow the page (in its
| > time-sorted display):
| >  http://cran.r-project.org/src/contrib/?M=D
| > and all of these were recently updates.
| >
| > If they don't show up, maybe time to switch CRAN mirrors and tell
| > cran@r-project.org?
| 
| Umm... yes, once one I know what exactly is going on, I'll report with CRAN...

Sure. And it is prudent to verify once or twice before crying wolf.

| > | The last should be reported to CRAN, but I don't have time today/tomorrow
| > | to explore these things.
| > |
| > | Dirk, packages with src/ seems to be nicely detected as non all... and
| > | compiling to binary code has not given problems on amd64 sofar...
| >
| > Awesome. And nice to detect my hardcoded i386 -- there will be more
| > shortcuts like that. We just need to test, test, test.
| 
| Sofar, I basically only need to add the '--binarch' option... no real trouble 
| with other hard coded stuff...
| 
| > | There are a few things that I think should be done:
| > | - split build/no-build, dependency, etc info into separate files
| >
| > I'm lost. What do you mean?  The config into at the top? In that case Yes!!
| 
| I was actually thinking not at the top, but in a separate file... or database 
| as you suggest..

Agreed, but let's start with a simple config file first. The db will make a
nice entry on the TODO list.

| > I was even thinking about a SQLite database (Perl and R can easily talk to
| > SQLite).
| 
| I don't have experience with SQLite... how would we add information to that? 
| Could we share the database in CVS?

A textfile, yes, I suppose.
 
| > | - changelog should indeed be cached in some way... so that we can keep
| > | track of what gets released
| > | - there seems to be too many dots in the description in debian/control
| > |
| > | Again, haven't had time to explore these in much detail... take all this
| > | as first experiences... btw, has anyone yet been able to run the
| > | cran2deb.pl fully successfully?
| >
| > I'm lost again -- how much did you run it?  It sounds like you did a full
| > load. Is that true?  
| 
| Yes, working on that.
| 
| > Did it all pass, i.e. the script finished? 
| 
| No. Since the deps were not all installed, and there were other problems, I 
| have to restart the whole process now and then... we should adapt the .pl 
| script to *not* stop when a build fails... and just report what failed...

I think I reported and abort on purpose as there is some implicit sorting
going on. I.e. it first builds packages with no depends, then packages with
simple depends and so on.  So whenever it fails, fix the cause, restart and
it pretty whizzes up to the point where it failed and continues.  

That way, with a few re-starts (but many, many build depends inflating my
system) I got to build the 400-some packages.

| Anyway, things are progressing. Not sure how far it went... 75 packages build 
| sofar... including the genalg package I contributed to CRAN :) There seem to 
| be 450 tar.gz...

Yes, it always grows.

| 
| > | PS. will be offline tomorrow.
| >
| > No problem.
| >
| > Thanks again for all this.
| 
| If we all contribute our bits, it should not be that difficult to have this 
| going in a few months... It's a side/side/side thingy for me. Busy with last 
| year of PhD, and working in spare time on open source projects, like Jmol, 
| JChemPaint and CDK (http://[jmol|jchempaint|cdk].sf.net), so I might be quiet 
| now and then... but I think that there is enough critical mass to get 
| momentum...

I guess we all have real jobs and other projects going. 

| There is something I 'worry' about at this moment:
| 
| people will start filing bugs at Alioth and we need to be able to close them 
| and add this info to the ChangeLog... so, I think, we really need to find a 
| way to preserve the changelogs... 

Just a new stateful directory "changelogs", preserved in CVS?  This may also
leads to patches.

| And a question: how is a new upstream release detected, versus a debian 
| release, like -2, -3, etc I mean?

See the Debian Policy and/or Developer Reference manuals. It's all in there.

| I've not looked at the debs yet. So no idea about the quality... More later.

Do "$ apt-get install lintian" and call lintian at the end of each built.
Lintian *is* your friend.

Keep up the excellent work, Dirk

-- 
Better to have an approximate answer to the right question than a precise 
answer to the wrong question.  --  John Tukey as quoted by John Chambers