[pkg-bioc] CVS %p

[David Vernazobres]

Hi Steffen, 

On Tue, Feb 27, 2007 at 11:25:05AM +0100, Steffen Moeller wrote :
> Hi David,
> 
> On Tuesday 27 February 2007 10:43:14 David Vernazobres wrote:
> > On Sun, Feb 25, 2007 at 11:01:23PM +0100, Steffen Moeller wrote :
> > > On Sunday 25 February 2007 22:12:15 Dirk Eddelbuettel wrote:
> > > When the scripts produces a new .deb file, pr when it is uploaded with
> > > mini-dinstall, is the apt-proxy internal information system automagically
> > > updated? If so, then there would be no need for the script to use dpkg
> > > -i, indeed. Otherwise the script should initiate the update of the
> > > apt-proxy somehow. Sadly, I have updated my apt to the one from
> > > experimental and cannot install apt-proxy or mini-dinstall due to some
> > > totally unnecessary conflict. python-apt: Depends:
> > > libapt-pkg-libc6.3-6-3.11
> > > and refrain from contributing at this front for the moment.
> >
> > May need to do it a bit of apt "magic", so we just update the local
> > repository, and not the full computer sources.list.
> >
> > mkdir -p /path/pkgbiocdevel/lists/partial/
> > apt-get -o Dir::Etc::SourceList=/path/sources.list.pkgbiocdevel -o
> > Dir::State::Lists=/path/pkgbiocdevel/lists/ update
> > and we could install with the same command line :
> > apt-get -o Dir::Etc::SourceList=/path/sources.list.pkgbiocdevel -o
> > Dir::State::Lists=/path/pkgbiocdevel/lists/ install pkg-to-install
> >
> > the resulting part is that we need to somehow, fix the directory
> > structure:
> > .../
> > .../tools   <- the cvs part
> > .../bioc
> > .../cran
> > .../omegahat
> 
> All changes that I have done to the script took care not to break anything 
> that is already existing. I do not exactly grasp how your plan will work out 
> since you will need a root directory to install the packages anyway, but if 
> it work and does not break anything, please go ahead.

I do not want to break something, I just would like to have a clean
build directory. When the list think that we must not change a single
things from the past, ok, but I think that some cleaning from time to
time is also good. 

>From cran2deb.pl when there is some declaration like :
 @dirs=("contrib/main","pub/R/contrib/main");
And we will add more directories in this search path each time someone
used a different kind of mirrors ?
Why not making directly a wget which is taking care of writing
in the sources directory with 

  wget -N --retr-symlinks -I"contrib/main/Descriptions" -nH \
    -m "ftp://cran.us.r-project.org/contrib/main/*.tar.gz" \
    --cut-dirs=2 -P sources

or
  wget -N --retr-symlinks -I"pub/R/contrib/main/Descriptions" -nH \
	-m "ftp://cran.de.r-project.org/pub/R/contrib/main/*.tar.gz" \
    --cut-dirs=4 -P sources
  
So we removed part of the complexity by having an homogeneous
bioc/cran/omegahat directories.
Each of these directories will have the following subdirectories :
builds html sources changelogdb.
  
I am thinking that it's also part of what you mean with 
"a reference build environment setup for CRAN,BioC and Omeghat all
together." Or are you referring just to the build part ?

> > > The next two big steps in the development of cran2deb remain (to me):
> > > * make %repositoryOf persistent - should be fairly trivial
> > > * create a decent build-dependencies tree and derive a same-as decend
> > > build order from it. I have no idea about how difficult this is - not
> > > toooo difficult I'd have thought but why have I not just done it?
> 
> > Using the recent graph theory ?
> 
> Indeed, my latest submission uses the Graph::directed class to model the 
> dependencies and knows how to use Graph::traverse::DFS to run through it.

Well, ok, I updated my directory and looked at your last changed.
 
> > > * a reference build environment setup for CRAN,BioC and Omeghat all
> > > together. Dirk suggests using pbuilder for it all, possibly helped with
> > > apt-proxy and mini-dinstall. The current sudo should be skipped for
> > > security concerns and exists only for the direct (and fairly easy)
> > > evaluation of the prior two tasks.
> >
> > I am starting to work on this part.
> > I think that apt-proxy is not necessary, and should not be necessary. We
> > should not extend too much the requiered architecture, in my point of
> > view.
> 
> If you do not need it - fine. So let's see what happens. I'd probably go for 
> the automated removal and additions of packages for the installation by 
> providing respective callback functions to the traversal.
> 
> Best regards
> 
> Steffen


Best regards,
david

-- 
David VERNAZOBRES, PhD student                     | dv at uni-muenster.de
Division of Bioinformatics, University of Muenster | Schlossplatz 4
(+49)(251)8321635                                  | D48149 Muenster
http://www.uni-muenster.de/Evolution.ebb/          | Germany