[pkg-bioc] debian/ simplifications

[Steffen Moeller]

On Sunday 22 April 2007 17:48:48 David Vernazobres wrote:
> On Sun, Apr 22, 2007 at 03:16:52PM +0200, Steffen Moeller wrote :
> > On Saturday 21 April 2007 20:07:53 David Vernazobres wrote:
> > > On Sat, Apr 21, 2007 at 09:47:38AM -0500, Dirk Eddelbuettel wrote :
> > > > I made another change to r-cran.mk, and so far all packages 'just
> > > > work' by only source r-cran.mk.   The newest one was to have
> > > > r-cran.mk grep for 'Priority: recommended' in the DESCRIPTION file
> > > > and then switch to installing into /usr/lib/R/library/ (where
> > > > reommeneded packages go) rather than /usr/lib/R/site-library/
> > > >
> > > > Are there other modifications we could or should address from
> > > > r-cran.mk? The 'repositories' idea is also implemeneted.  A few month
> > > > ago I added inclusin of debian/overrides for Lintian, if found.
> > >
> > > cool,..
> >
> > Yip!
> >
> > Something I cannot stop thinking about since  had to remove some
> > cran/bioc because of some disk space problems emerging: Could we get the
> > LaTeX bits separated and possibly some other bits implemented in order to
> > reduce the minimally required resources a bit?
>
> Hum, reducing, yes definitely. But I did not get the LaTeX part ? What
> are you referring to ?

moeller at pc02:~$ dpkg -L r-cran-tkrplot
,..
/usr/lib/R/site-library/tkrplot/html/TkRplot.html
/usr/lib/R/site-library/tkrplot/latex/TkRplot.tex
..

> > > > Also, I no longer include the basically empty postinst/postrm.
> > > >
> > > > Lastly, one thing I find confusing when building the few dozen
> > > > r-cran-* packages I manually maintain:  Sometimes an R  package is
> > > > NOT listed in Depends: yet required under pbuilder (probably due to
> > > > LazyLoad or something).
> > >
> > > well, in cran2deb I am still adding dependencies from time to time
> > > manually. It's not a long term solution, but a solution.
> >
> > We should strive for a close link to the upstream developers / bioc
> > organisers to feed our manually determined dependencies back into their
> > descriptions. We could e.g. publish our list ... hm ... we have it in a
> > database now, don't we? I could come up with a script to do that.
>
> Yep, a kind of csv format file, that we import in the db at each run.
> The DB need to be improved, with a web interface (in rails),... but well
> I have a really busy month in perspective, so I won't have some real
> coding free time....

A real web interface with which comprises write access may be overdoing it. 
From my point of view it could just be a flag to the current script as a 
start. I think our wiki page should point to the CVS directly where we have 
an html variant submitted on a regular basis.

> > > > How reliable is the Depends/Suggests information in DESCRIPTION
> > > > for us?
> > >
> > > Well, very low I will say. But some packages' descriptions are very
> > > good. So, it's a starting point.
> >
> > I presume that upstream developers just never built their bits from
> > scratch and are even plain unaware of their package's dependencies when
> > writing the descriptions. I think that our work and the fixing of the
> > dependencies is some kind of contribution to upstream, too. We just need
> > to redefine our work a bit :-)
>
> Yes,... but it take time to do it manually, need to come with a
> solution, or a redefinition of the packaging task.

Ok.

Steffen