Using recent packages on stable systems (Was: Depends available in other PPA's)
Hi Benjamin
On Thu, Mar 08, 2018 at 10:14:04AM -0500, Benjamin Redelings wrote:
> I'm Ben Redelings (http://ben-redelings.org) and I've recently joined
> debian-med on salsa. I've been thinking about uploading some new
> phylogenetics / bioinformatics software, partly so that I can tell students
> in workshops "just type sudo apt-get install <packages> if you are running
> debian or ubuntu".
>
> For this use case, I probably can't tell everyone to run debian testing
You are right that testing is not always a sensible choice. If users
are running Debian stable we can do backports[1] of software from
testing. This is a well established method to have recent software on a
stable system and there are tools inside the Debian infrastucture that
enable control about the status of these backports.
> - a lot of people are going to show up running ubuntu. What might you all
> recommend? In theory ubuntu people could add debian testing to
> `apt/sources.list.d`.
I do not think that it is a good idea to mix Debian testing with Ubuntu
randomversion. IMHO the most sensible way to go would be to use the
backporting system the NeuroDebian team has developed. They are doing
automatic backports to Debian stable / oldstable and several Ubuntu
versions. Its a real pitty that this nifty system is only used by
NeuroDebian and nobody took the time to make this a bit more generic to
make it useful for all Blends (NeuroDebian team are basically two very
kind and helpful but totally overworked people who will not spent their
time to port their scripting system for any other use - so we are on our
own if we want to use it).
> I have no idea how much conflict that would cause -
> perhaps ubuntu users could set the priority of testing to something lower
> than ubuntu in apt/preferences.
That's just a hack and I would not rely on this.
> I could also try to make my own PPA called bredelings/bioinformatics or
> something like this, and only maintain packages that I am interested in...
That would just be another PPA and I do not see in how far this should
be better maintained by you as a single person than the current PPA is.
If you would *really* like to care for the current one - just use the
existing one where others might be able to contribute. I expressed my
bad feelings about the existing PPA since there is no real control about
what's endung up there and what not. Can you tell how many packages
there are featuring release critical bugs? I'm sure there are such
packages - and which of these are affecting the system you want to use?
We are currently working heavily on equiping possibly all at least the
most frequently used packages with continuous integration support. Most
of the packages inside the PPA are older than the packages with those
tests and no test is run on this PPA since there is no infrastructure
behind. So using the current status of the PPA is basically equivalent
to throwing away the good work we did in the past 2-3 years in the
Debian Med team.
When looking at the time stamps I can see 9 packages uploaded in 2018-02
(when we had the sprint) and no upload in 2017 at all. May be I missed
something at the sprint but I have not heard that somebody said: Hey, I
would love to update all the packages (we have > 500 biology related
packages and some preconditions will be needed as well). I'm positively
convinced that even if somebody would work full time on following our
uploads to unstable to upgrade the PPA this will not scale. So we need
an automatic system and tools that provide some reliable quality and not
just a random apt-get source of outdates biology software. If we do so
I'm afraid users will learn that the Debian Med project provides
outdated and buggy software which is something I would like to avoid.
> Thoughts?
Short summary of the alternatives I would see
1. Use Debian backports for Debian stable users (my institute is
happy with this approach)
2. Craft an automatic backporting system following the NeuroDebian
example (volunteers?)
3. Start maintaining the PPA properly (an additional one would be
even worse)
4. Check whether BioLinux fullfills your needs (see Tony's mail -
I'm not competent for BioLinux since I never tested it)
Kind regards
Andreas.
[1] https://backports.debian.org/
--
http://fam-tille.de
Reply to: