Sven Luther wrote:
> I understand there is some articial problem in doing new uploads to unstable
> for packages that produce .debs, but i don't know, now that rc3 is declared
> final, if this still applies or not, but i would really appreciate that the
> d-i build system gets fixed and that sarge release candidate d-i's get built
> from sarge .udebs, in order to not cause additional burden on maintainers in
> their daily work on packaging.
None of this has anything to do with sid udebs; d-i builds targeted
at sarge have used sarge udebs since early last year; see the code
and/or changelog.
Like any Debian package, d-i initrds are built on the autobuilders.
Which, at least until t-p-u is available, run unstable. Like any binary
that statically includes a library[1], a d-i initrd image built on an
autobuilder will include the version of that library that was installed
on the machine that built it. I'd expect you to be familiar with this
concept since you run the d-i powerpc daily build.
Anyway, this means that certian changes to libraries in unstable do have
the potential to impact d-i builds that are targeted at testing. This is
also true of various and sundry other packages in Debian. It's not
something that we've historicaly lost sleep over, even though I think
it's likely that past Debian releases could have included a few binaries
statically liked to library versions not in the release. Which might just
violate the LGPL, and could cause QA issues.
For d-i, the potential for RC breakage due to library skew is increased
since d-i absolutely has to work. Also, the potential breakage due to
library skew is slightly increased since we not only link binaries in
the initrd against the library in it, but load udebs that may also link
to a library from the initrd. If an unstable and broken library leaks
onto the initrd, it may work fine with what's on the initrd, but break
some udeb that links to it. Hypothetically.
The set of libraries[2] that are included in d-i initrds is slang, newt,
libdiscover1, ncurses, glibc, libbogl, libtextwrap1,
libdebian-installer4, and libdebconf-client0. I trust the maintainers of
these libraries to not screw up the version in unstable and break d-i.
libparted is included in some monolithic initrds, but we are not building
those by defauit.
Of course all the standard reasons why resuming post-sarge development
work of d-i components in unstable is unwise right now still apply --
- If an update needs to be made to testing, for whatever reason, it
cannot be, until t-p-u becomes functional.
- We become unable to test d-i daily builds and know that the test
results will apply to sarge too, since we're testing images
containing post-sarge changes. This can be worked around by setting
up sarge d-i daily builds for all arches, but we currently have only
2, and once we have the full set they'll still get less through
testing.
These issues have been sufficient for the d-i team to decide to hold off
on such changes with the exception of some changes to arch all packages
(that are not affected by the first issue). Even though most of us,
myself included, find this quite painful, and some of us worry that
we're losing months of valuable post-sarge d-i development time. We
think that being able to deal with any issues before sarge is released
and having a good sarge release is worth it.
Whether you comply with or disregard this decision of the d-i team is, I
suppose, up to you.
--
see shy jo
[1] We don't actually statically link, but the static linking analogy is
very appropriate.
[2] BTW, A few boot loaders are also included on d-i initrds and have some
of the same potential problems as these libraries if changed in
unstable. Which is one reason why the new syslinux is in experimental.
Attachment:
signature.asc
Description: Digital signature