Re: Sub-backports?
On Fri, May 26, 2017 at 02:17:50PM +0200, Johannes Ranke wrote:
>...
> 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.
>...
Having too strict dependencies is better than breakages for users due to
missing dependencies.
The right thing for #861333 in buster would have been the r-api-*
approach with an upload to experimental first and then reqesting a
transition slot from the release team.
Regarding R and backports:
What do you expect to happen with already installed R packages if R
3.4.0 ever enters stretch-backports, and a user does
apt-get -t stretch-backports install r-base-core
Handling that properly would not only require properly changed r-api-*
dependencies from buster, any attempt to replicate such a transition
properly in backports would result in things like +b1~bpo9+1 packages.
> Cheers,
>
> Johannes
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: