Re: Sub-backports?
Hi Steffen
Am Freitag, 26. Mai 2017, 13:51:16 CEST schrieb Steffen Möller:
> For Debian Med we have a similar situation, not as bad though, as with
...
> bit of a provocation, but could we think about a concept that would both
> be close to the distribution and allow for the needs of particular user
> community?
Good idea.
I am trying to achieve this with the archive for R backports to Debian stable
(and testing when it's frozen) on CRAN
https://cran.r-project.org/bin/linux/debian/
As R just made a change for R 3.4.0 that made some depending packages compiled
on earlier versions incompatible with R 3.4.0, I decided to create a new
repository for R 3.4.0, so people would not automatically fetch an update that
breaks their packages.
But this is a lot of manual work and it would be better if we could properly
deal with this using r-api-* or using lists of Breaks: in the main Debian
archive as suggested here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333
and then use the official Debian backports repository. Using r-api-* (similar to
python) would affect a lot of packages that are not really affected by the
problem, and maintaining a long list of versioned Breaks relationships is
painful for the sole maintainer of R in unstable.
At the moment, the version of R in unstable could not be uploaded to stretch-
backports after the release due to this bug. The good thing here is that R
3.4.0 has not entered and will not enter stretch.
The bottom line is: Yes, dedicated repositories can be maintained on any web
server, even by a single person (which is far from ideal). But doing things in
Debian and backports properly is much better, as far as I can see.
An intermediate solution like PPRs for specific communities would introduce a
whole new set of potentially messed up upgrade paths, I am afraid.
Cheers,
Johannes
Reply to: