Re: Sub-backports?
On Fri, May 26, 2017 at 01:51:16PM +0200, Steffen Möller wrote:
> For Debian Med we have a similar situation, not as bad though, as with
> the Django packages: Strong inter-dependencies between packages. This
> happens whenever there is some kind of framework has a non-monotonic
> feature change. Our Django is R. It is mostly fine, but when we are not
> careful, then an update of R in backports would require many other
> packages to compile or to be updated. And when we say that we support a
> particular version of BioConductor, which depends on a particular
> version of R, then we have to somehow do just that have the right
> versions of packages together because that is what this version of
> BioConductor is having. And we have all the same problems (or would have
> if we would do backports) when the release of BioConductor is not in
> sync with the release of Debian.
Looking at #861333, I have the strong impression that R should not ever
be in backports.
Installing a package from backports to stable should be smooth,
with the dependencies ensuring that you end up with a combination
of packages where everything is working flawlessly together.
(But there will usually be more bugs than with a stable-only system.)
> Take home message of the above: Django is not alone.
>
> I am not exactly sure about what we should do about it all. I just see
> some further scenarios:
> * go through testing is fine, but what do we do while we are in a freeze?
The primary goal for Debian maintainers should be to have as good as
possible packages in stable.
testing is not just a tool for getting software into backports,
the software that is right now in testing is what the users of
stretch will be using during the next 5 years.
> * what when we want to offer multiple version of Django/BioConductor
> with their very own sets of versions of associated packages?
backports are a good workaround when you have a >= requirement on some
software that is not fulfilled in the current stable.
E.g. when you have hardware that is only supported in kernel >= 4.4
the kernel from jessie-backports solves your problem, and kernel 4.9
in backports is an equally good option.
Strict = version requirements are not inside the scope of what backports
are supposed to provide (unless this happens to be the version that will
also end up in the next stable release).
> I am with Alex (my past AM, hello) that the current policy has mostly
> worked. But I also tend to think that we need something for communities
> that have their very own understanding of what a release is that is
> mostly independent from the underlying OS. Ubuntu can get there via
> their PPA infrastructure but I find that confusing since the user does
> not know what PPA to trust and which not so much. My subject line was a
> 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?
What is being discussed as "bikesheds" would be the Debian variant of PPAs.
The root problem in this discussion is that they do not (yet) exist,
and people are instead (ab)using backports for that purpose.
> Best,
>
> Steffen
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: