Steven Chamberlain <email@example.com> (2014-08-20): > On 14/08/14 18:15, Cyril Brulebois wrote: > > [...] If a > > single extra udeb (or udeb size increase, which happens from time to > > time) is going to break kfreebsd-*, it seems to me that their status > > is far too brittle. > > The fixed-size d-i initrds had to be carefully sized for kfreebsd > wheezy. That this was the case for wheezy already isn't an excuse. I really don't think it's viable to play the "let's save a byte here or there" game. Even if that were the case, someone has to care, and commit to actually ensuring that constraints are met, and that d-i works. Look, I don't like releasing broken things. Especially when it looks to me I'm the only user, and not even a real one, just a beta tester. > We discussed about a year ago the possibility of adding a variable-sized > ramdisk to avoid ENOSPC, for anna/cdebconf in particular. It may affect > our minimum RAM requirements. Is that a viable option for jessie? > And/or we could maybe lose some unnecessary udebs. I mentioned > partman-iscsi as an example to start with (I also didn't understand > how/why that was being included in the image at all?) but there are > probably other and larger candidates. If you're trying to insinuate I/we deliberately broke kfreebsd-* by introducing partman-iscsi, rest assured that: no. Can we please figure out a way to unbreak kfreebsd *most of the time* and stop caring about this single package? Extra udebs are sometimes added. That shouldn't be the end of the world for release architectures. And when breakages happen, there really should be someone to detect them, and deal with them. Mraw, KiBi.
Description: Digital signature