Re: Packaging r-bioc-simpleaffy

[Andreas Tille <andreas@an3as.eu>]

[CC to debian-blends because it might concern other Blends seeking
 ways to handle external archives.  Short intro: BioConductor contains
 a lot (> 1000) R packages which are turned automatically into Debian
 packages using cran2deb.  There is a big interest in these packages
 but there is no chance to get them all into Debian because we have
 on one side no manpower to check them all licensewise and we also
 do not want to run a denial of service attack on ftpmaster.]

On Sat, Feb 26, 2011 at 11:05:49PM +0100, Steffen Möller wrote:
> When looking at how Debian is working today, then what you said above
> seems true. But maybe we generate ideas how to keep something separate
> and nonetheless announce it a bit more and/or make installation. For
> all reading this who might not have looked at it, yet:
> 	http://debian-multimedia.org/
> is fantastic.

While I'm using it myself I would not call it fantastic.  I have learned
to know several people who consider it a very bad way to provide
non-free and even more importantly non-distributable software which is
not tested in any way and conflicts with properly maintained Debian
packages.  While the truth is probably somewhere inbetween and I do not
share this option - even if I just was running in some version conflict
problems which was quite annoying and the contrary of fantastic.

But we are in a different (and better) position than debian-multimedia:
We are not talking about non-distributable software.  As far as I
understood we just have the external archive of the BioConductor
software and for the moment we assume that the software inside is
distributable (it is just not checked if this is true).

We could even add all those packages as "Suggests" to a metapackage (we
can not use recommends because recommended packages need to be in main)
and since apt 0.8.11.2 finally #473089 was fixed and provides a simple
to find way to install suggested packages (--install-suggests) this
could easily provided to users in conncetion with a sources.list line as
I suggested in my last mail.  In contrast to debian-multimedia this
situation is much better (provided that really all licenses of
BioConductor really allow distribution).

The only problem we have is that we are not able to properly advertise
these packages apropriately on our tasks pages - and this was an
explicite and fully reasonable requirement in your mail to do proper
advertising and not learning about something by chance.  But we have no
information about these in UDD and thus can not put them on our tasks
page.  I actually have a plan to import external sources into UDD (I
have even code ready to inject SkoleLinux archive into UDD modulo some
testing) we could inject such a BioConductor archive into UDD and
somehow tweack this information into the tasks pages.  This has just to
be worked out in the Blends scope properly.

> Maybe we even get Tony back to Debian after a look at
> it (just kidding).

Kidding?  That's just a matter of time. ;-))

> I am still annoyed that it was mouth propaganda
> that brought me to it and not some official Debian page.

Mouth propaganda??? It's the first Google Link for "Debian Multimedia"
search ... and there is a reason why people who work on properly
distributable multimedia packages do not really like this.
 
> The external repository should be fine as long as there is no package
> in Debian main dependening on something from the external repository.

... and not "Recommending" (that's an important point).  We can only
Suggest packages outside Debian main archive.

> And when that happens, well, then those dependencies would indeed need
> to be adopted.

What we currently do in Blends frame is to verify whether a package
which is mentioned as "Depends" in the tasks page is really in main and
if it is not it is only Suggested.  That will be possible to do also
with BioConductor packages.  However as long as we can not inject the
metainformation of such packages we can not properly put them on our
tasks pages and we have no real QA control over these packages (can
not use BTS etc).
 
> > That's IMHO a fair reason to inject the most
> > important (=the packages which are explicitely requested by our users)
> > into official Debian.
> 
> I would wait for the explicit demand for those to be added.

Well, Tony just mentioned some interesting package and if time permits
(or some volunteer steps up) we can package it manually - IMHO that's no
conflict at all.  We just have packaged several packages from CRAN as
well.
 
> > If we advertise the option how to enable an
> > external repository (perhaps by providing examples for
> > /etc/apt/{sources.list.d,preferences.d}) the problem of high frequency
> > updates is not that urgent as it was mentioned by Steffen.  I'm actually
> > not fully convinced that every scientist really wants to update his
> > system that frequently and is keen on following upstream updates all the
> > time.
> 
> You are definitely right. Many will not like it. Es Tony said,
> especially not so while a particular project is running. One would
> need to set a package on hold, then, or just not update at all.

Either this or we might keep some more "stable" and highly requested
packages of BioConductor inside Debian in a highly tested version and
leave the Bioconductor2Deb packages archive for people who want the
latest and greatest (which does not conflict with everything I suggested
above).
 
> We should somehow start with external repositories and see what we
> can learn from it. We have two - one is the Ubuntu 10.04 based Bio-Linux
> and the other now is the CRAN/BioConductor - and one obvious issue
> is that neither will be completely compatible with Debian stable.
> What exactly this means in practice we don't know yet. Our luck for
> CRAN/BioConductor is that the version R in unstable is backported to
> all versions of Debian and those of Ubuntu. This way we have a
> pan-release interface for the packaging -- at least for the platform-
> independent packages. For the others - let's see and think.

So the plan is clear: We find even more studios packagers for the
packages we spotted as important which take over what is on my packaging
agenda which gives me the spare time which is needed to properly
finalise the work I started on external Blends archives. :-)

Kind regards

       Andreas.

-- 
http://fam-tille.de