Re: Maintaining intermediary versions in *-backports
On Wed, 24 May 2017, Neil Williams wrote:
> > > Policy is not a stick to bash developers or users. 1.8 needs to stay
> > > available in backports at all costs.
> >
> > Backports is not there to fixup maintainers mistake.
>
> It's not a mistake. It is simply a timing issue. There was no window to
> get the LTS into Jessie.
But you could have brought 1.8 into stretch, alongside
the next version, with differing package names, right?
(Though I admit that’s likely not fun either, especially
handing over conffiles, databases, etc. from one package
to the other.)
> > No, it doesnt. They already ARE RC Buggy and should all get a bug
> > against them. stretch main must be self contained, if it needs
> > something from outside of it, its an RC bug.
>
> What it needs from outside Stretch is the user data.
>
> Fresh installs of these packages work and have always worked.
>
> It is the user data during upgrades that is the problem here. We're
Hm, okay, but still… can’t you add the upgrade mechanism
upstream clearly had to the packages in stretch? I think
upgradeability from Debian $x to Debian $((x+1)) has always
been required for packages with the same name?
> talking about a major change to how the database is managed. That
> cannot be cherry-picked out of 1.8.
Other packages do so?
bye,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
Reply to: