Re: Packaging r-bioc-simpleaffy
On 02/26/2011 10:12 PM, Andreas Tille wrote:
> On Sat, Feb 26, 2011 at 01:59:51PM +0100, Karsten Hilbert wrote:
>> Does this not mean that there ought to be a more convenient way for
>> users to discover that they need to activate an additional repository
>> (say, by somehow providing "pointers" from dummy meta "packages" within
>> the main archive towards other repos, or else via some tasks-like
>> mechanism or some such) and a user-friendly way of enabling such
>> repos ?
>
> I'm not against a separate repository. However, regarding advertising
> packages via package dependencies properly (and in turn having them
> mentioned accordingly on our tasks pages) we con only do this with
> official Debian packages.
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. Maybe we even get Tony back to Debian after a look at
it (just kidding). I am still annoyed that it was mouth propaganda
that brought me to it and not some official Debian page.
The external repository should be fine as long as there is no package
in Debian main dependening on something from the external repository.
And when that happens, well, then those dependencies would indeed need
to be adopted.
> 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.
> 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.
>> To provide this infrastructure is surely out of scope for Debian Med
>> proper but seems to be a useful target for Blends as such but needs
>> to be implemented in core Debian.
> I'm in favour of a general Blends solution but this solution is
> definitely limited to some constraints mentioned 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.
Steffen
Reply to: