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