Re: Using recent packages on stable systems (Was: Depends available in other PPA's)
On Fri, 09 Mar 2018, Andreas Tille wrote: > > > > - 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). > > Hmm... the 'Get NeuroDebian' section at neuro.debian.net does look nice. > +1 > > I don't suppose the code for the backporting system is hosted at a > > particular place that I could take a look at?� Since I am new I probably > > couldn't/shouldn't do much, but I would be interested in taking a look. > NeuroDebian members usually are reading this list but I'm CCing their > list explicitly hereby. I guess it will be in some public Git repository > which you can clone and enhance. moreover it is just an apt-get install neurodebian-dev away from you :-) Also in git at: http://git.debian.org/?p=pkg-exppsy/neurodebian.git http://github.com/neurodebian/neurodebian so choose your poison A few bullet points relating to it - our distributed and still used by me system is aged but still works. Michael has/is using a newer version he came up with for scheduling builds using condor etc. - the core backporting helper (backport-dsc) is aged but still working. It was "offered" to be included to devscripts https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660208 but it never happened. That one allows to automate creating backport source package, possibly while also applying distro specific patches (quite often that is what keeps me remaining benevolent maintainer for some packages since others prefer to not have any additional non-debian patches within Debian source package) - nd_backport is just a wrapper around backport-dsc to provide neurodebian specifics - nd_build is to build a (backported) source package on any cowbuilder - nd_build4allnd wrapper/looper around nd_backport and nd_build to build on all "supported" Debian/Ubuntus given an original .dsc file here is an elderly howto which might still work 90%-100% of the way http://neuro.debian.net/blog/2012/2012-04-14_ndtools.html hope this helps -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Re: Using recent packages on stable systems (Was: Depends available in other PPA's)
Hi, On Thu, Mar 08, 2018 at 03:26:11PM -0500, Benjamin Redelings wrote: > > > - 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). > Hmm... the 'Get NeuroDebian' section at neuro.debian.net does look nice. +1 > I don't suppose the code for the backporting system is hosted at a > particular place that I could take a look at? Since I am new I probably > couldn't/shouldn't do much, but I would be interested in taking a look. NeuroDebian members usually are reading this list but I'm CCing their list explicitly hereby. I guess it will be in some public Git repository which you can clone and enhance. Kind regards Andreas. -- http://fam-tille.de
Re: Using recent packages on stable systems (Was: Depends available in other PPA's)
Hi, On 03/08/2018 11:27 AM, Andreas Tille wrote: - 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). Hmm... the 'Get NeuroDebian' section at neuro.debian.net does look nice. I don't suppose the code for the backporting system is hosted at a particular place that I could take a look at? Since I am new I probably couldn't/shouldn't do much, but I would be interested in taking a look. -BenRI
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 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
