Bug#746715: the foreseeable outcome of the TC vote on init systems
On 05/06/2014 11:11 AM, Raphael Hertzog wrote:
> For instance, to date, we still don't have a newer syslinux in unstable
> while he was eager to push syslinux 5 in unstable during the former
> freeze
1. syslinux 6 prior 6.02 was not usable because the efi things caused
regressions in the non-efi bootloaders (e.g. pxelinux was broken for a
very long time; see #syslinux and syslinux@l.s.o).
2. due to required changes in the debian packaging, the package had to
go through new (twice; the last time it rottet there for ~6 weeks, the
previous one was iirc in NEW even longer).
3. you very well know that even if 1. and 2. wouldn't be a problem, i
couldn't upload syslinux 6 directly to unstable without first getting
the packages depending on syslinux 4 behaviour adjusted (syslinux
upstream changed incompatible between version 4 and 5, see
https://lists.debian.org/debian-release/2014/05/msg00016.html).
so, while you where holding the 'speedy' upload of syslinux 5 to
unstable against me, at the same time you're now holding the causious
upload of syslinux 6 to unstable against me as well? i seem to never be
able to do it right for you, no matter what.
> (and I still don't agree with his migration plan
> given in #742836 that he closed twice without trying to see whether
> I agreed and whether I would not have additional advice...)
as usual, i'm open for anything constructive. you might want to read my
second message to the bug carefully to understand the whole issue
though. let me know if you have any questions left.
> The lxc package was severly out of date ever since the wheezy release up
> to a few weeks ago. Etc.
lxc changed incompatible with almost any in-between release until they
settled for their stable 1.x series (well, between 1.0.0 and 1.0.3 which
are supposed to be stable releases, they changed significantly again,
but that's another story). thus not having a sane upgrade path, and
having to refactor the debian additions due to the request from Lucas,
it was imho the better way to handle it that way and only provide a
stable LXC to unstable when ready, rather than to break users machines
with almost every update. ymmv.
Regards,
Daniel
--
Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.baumann@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/
Reply to: