[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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
